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ABSTRACT 



Tne INTEL 432/670 microcomputer system contains tne iAPX 
432 microprocessor which executes compiled Ada programs. 
This thesis contains performance evaluation of the INTEL 
432/670 system in a multiprocessor/multiprocess environment. 
Benchmaric programs from the Computer Family Architecture 
(CFA) study are encoded in tne Ada PrOi^ramming Language and 
compiled on a host VAX 11/780 before being downloaded to 
INTEL MDS 800 for further transfer to the INTEL 432/670 
system for execution. The historical development of computer 
architectures as well as a systematic description of tne 
INTEL 432/670 system are included. 
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I. INTRODUCTION 



A. BACKGROUND 

An Integrated Circuit (IC) is a small silicon 
semiconductor crystal containing electrical components sucn 
as transistors, diodes, resistors, capacitors, or 
interconnected digital gates. As tne technology of IC's has 
improved, tne number of components tnat can be put on a 

single silicon chip has increased. If a pacicage contains 
several logic gates it is considered to be a small-scale 
inteseration (SSI) device. Medium-scale inteeeration (MSI) 
devices contain 10 to 100 gates and perform a complete logic 
function. Large-scale integration (LSI) devices perform 
logic functions with over 100 devices and very-large-scale 
Integration (VLSI) units contain thousands of gates in a 
single chip. The INTEL iAPI 432 contains 160,000 transistors 
on two chips and is considered a VLSI device. 

B. THESIS DESCRIPTION 

The Intel 432/670 system is a commercial product tnat 
uses the iAPX 432 microprocessor. Incorporating many new 
architectural features, with the goal to significantly 
reduce the software cost, tne Intel 432 has been neraiaea as 
"the most significant architectural development in tne last 
5-10 years" [Ref. ij . In addition to tne VLSI tecnnology, 
the 432 contains architectural advances that enable 
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implementation of transparent multiprocessing and a 
protected computing and communications environment. 

The purpose of this thesis is to continue a series of 
benchmark performance tests on the Intel 432 that have been 
reported in Shoop [Ref. 2J and Applegate [Ref 3J . Tne goal 
of these tests is to determine if the 432/670 system is 
capable of sustaining incremental performance improvements 
as processors are added to the system. 

C. THESIS 0R5ANIZAT0N 

This thesis is composed of three major sections. Chapter 
II presents a brief history of computer architecture 
development from the first electronic computers to tne 
object oriented architectures. Chapter III provides a 
systematic description of tne Intel 432/670 system while 
Chapter 17 provides the actual Bencnmaric performance 
evaluations of the Intel 432/670 system in the 
multi processor /multi process environment . 
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II. HISTORICAL DEVELOPMENT 



Since computer systems architecture is not restricted to 
the sole aspect of hardware, it is not easily defined. 
Junctional boxes and their complexity, the interconnection 
between tne boxes, switcnes, controllers, tne way messages 
are passed and received, and tne blend of hardware and 
software features must be considered in tne overall 
architectural structure. The Intel 432 architecture is the 
result of an evolutionary development in computer systems. 
It incorporates many advanced features whicn nave evolved 
throughout the history of computers. Accordingly, to 
establish tne proper perspective of the concepts of tne 
Intel 432 a brief history of computer architecture 
development is presented. 

One of the earlier electronic computers was completed in 
1946 at tne University of Pennsylvania Moore Scnool of 
Bneineerin?. ENIAC, capable of performing nearly petfO 
additions or subtractions per second, consisted of more than 
1800fe! vacuum tubes and 1500 relays and was used to compute 
ballistic trajectories. Wired for specific computations, any 
modifications or program replacements on ENIaC required new 
wiring and its associated excessive set up time. In an 
effort to eliminate the setup time, von Neumann and others, 
consulting at tne Moore Scnool of Engineering, designed tne 
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tne 



first stored program computer. However, tne first 
operational stored program computer (EDSAC) was built at 
Cambridge, England in 1949. In addition to being tne first 
computer to execute stored programs. EDSAC introduced tne 
notion of memory nierarcny tnrough the primary memory and 
backing drum. 

Meanwhile, von Neumann continued his researcn at the 
Institute for Advanced Studies (IAS) at Princeton where ne 
developed the von Neumann architecture which is in wide use 
today. The von Neumann architecture is considered to be 
based on four Key concepts: 



1. A single, sequentially addressed memory, 
program and its data are stored in a sing! 
memory, and the memory is referenced with 
sequential addresses. 

2. A linear memory. Tne memory is one 
dimensional, or nas tne appearance of vector 
of words. 



3. 



No explicit 
and da ta . 
distinqui sned 
directed toward 



distinctions 
Instructions 
implicitly 
them . 



between 

and 

by the 



instructions 
data are 
ope ra t i ons 



4. Meaning is not an inherent part 
[Ref. 4J 



of data. 



The early programming styles supported single user, non- 
subroutine environments that employed a looping technique by 



modifying instructions. Since instruction modification 



generated only 
not feasible 



serially reuseabie code, mul tiproerammin^ was 
and index registers were developed at tne 
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University of 'lancnester to maKe it possible to call 
subroutines, pass parameters, and generate reentrant coae. 

UNIVAC I, built for tne Bureau of Census, nad a tape 
system taat used error cnecKing procedures and buffering 
capabilities to read tapes bota forward and backward. It was 
intended for bota scientific and commercial applications and 
can be considered tne first successful commercial computer. 
Tne system arcni tec tur-e durine tnis period is caaracterized 
in Figure 2.1. 



I 

1 MEMORY 



CPU 



I/O 



I 

I 



PERIPHERALS 



Figure 2.1 Early System Arcnitecture 



As computer applications advanced into 
fields, I/O intensive requirements were 



commercial 
genera ted . 
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Arcfii I6cture Improvements to ennence computational speecs 
and enable overlap to permit interleaved I/O and 
computational operations were developed. Pipelining, a 
tecnnique used to speed computer operations by multiplexing 

memory accesses .pa with instruction decoding and execution, 
is one example of enoancement . 

Systems became faster, smaller, and more reliable 
tbrougbout the 1960's as transistors and integrated circuits 
allowed the building of more general purpose registers and 
regular architectures. Figures 2.2, 2.3, and 2.4 depict the 
architectures of this period. 



CPU 





PEHIPHSRALS 



Figure 2.2 Dual Port Memory Architecture 



Figure 2.2, representing 
architecture, provides a faster 
extra hardware in the memory which 



a dual port memory 
access path but demands 
performs independent I/O 
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operations. The I/O ous structure, Figure 2.3, connects tne 
I/O devices to memory tnrougn device controllers tnat are, 
in many cases, mini-computers. It still requires a resource 
manager or a distributed control discipline. Tne central 
system controller shown in Fisrure 2.4 is based around a 
giant switch which controls multiple processors and memory 
units in a modular fashion. 



CPU 



i 



I I 

i MEMORY ( 

I I 

I I 



j DEVICE ! j DEVICE j DEVICE | 

I CONTROLLER 1 CONTROLLER j ! CONTROLLER ! 



Figure 2.3 I/O Bus Architecture 

As hardware cost decreased, designers eliminated the 
complicated central I/O control in favor of a ous oriented 
structure (Figure 2.5). It is flexible, modular, and 
conceptually simple and most architectures today contain 
variations of this bus oriented structure. S-100, MULTIBUS, 
EXORBUS , and VMSbus are a few bus oriented architectures on 
tne current maraet. 
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Figure 2.4 Cemral System Controller 



As fast processors wer® developed, efforts to iceep tde 
processors busy, wnile tne slow peripnerals were reacting to 
instructions, culminated in mul tiprosramminff and tne 
associated tast swi toning and nardware memory protection 
instruction set ennancements . Microprogramming, a tecnnique 
wnicn breaks eacn instruction into a series of elementary 
steps was also developed in the 1960's to reduce tne cost of 
the sophisticated instruction sets by making it easier to 
develop a compatible series of computers that covered a wide 
range of performance. 

Paging and segmentation were developed to support tne 
concept of virtual memory. Additionally cacne memory, whirn 
is fast memory pnysically close to tne central processor, 
was developed to improve CPU performance. In general, tne 
advances in memory management resulted in a five level 
hierarchy that consisted of registers, cache, main memory. 
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and nlgn-speed dist or drum for Dacning store and low-speed 
list or tape for lon^-term program storage. 
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I PROCESSOR I I PROCESSOR | | 



Figure 2.5 Single Bus Arcnitecure 



Multiprocessors, anotner concept introduced in tne 
1960's, are cna racteri zed arcnitecturally by wnetner tne 
processors are identical, execute the same instruction 
stream, or operate on one or more data streams. However, it 
was the Intel microprocessor which was developed in 
1971 that was responsible for a continued unpresidented 
evolution in technoiosy during the 1970's which produced tne 
Inexpensive processors and encouraged the use of 
mul ti processsine. Specialized database processors and 
arithmetic processors are a few examples of expansion in 
this area. 

As complexity in microcomputer systems increased with 
decreasing hardware cost, software systems were expanding to 
taKe advantage of the new capaoiities. Software engineers 
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soon discovered tnat large software systems were among tne 
most difficult eneineerin? projects. Tde use of subroutines, 
bloct structured languages, procedures, functions, stepwise 
refinement and structured prcsrammin? were tecnniques 
developed to assist in solving tne software engineering 
problems. Data abstraction, employine tne concepts of 
encapsulation of data structures, uniform procedure/message 
interface, and decomposition of design, was a furtner 
extension of the effort to produce reliable software. 
Wnile these software concepts were being developed, 
evolution in hardware protection structures can be observed 
in "supervisor vs. user state in tne IBM 360 systems, 
hierarchical rings in Multics, and multiple domains in tne 
Plessy s/250, CAL/TSS, Hydra, and CAP. Key concepts of these 
domain based systems include independent address spaces, 
capability-based addressins and access control, and the 
decomposition of tne operating system into a useful set of 
abstractions.” [Ref. 5j Additionally descriptors and access 
control concepts were introduced to provide protection by 
establishing a reouirement for authorization to access data 
elements . 

A major departure from one of the Key concepts of the 
von Neumann architecture is observed in tagged storage. All 
information within storage is se if -identifying. Based on tne 
information contained in the tag field, the machine 
instructions can determine tne semantics of eacn operation 
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as well as tne data conversion rules to employ. rfitn tne 
tag field you nave a strongly typed environment' mat 
prohibits operation on improper data types and permits the 
deferment of binding instructions to data attributes until 
the time of execution. 

As we examined tne nistory of computer development, we 
saw that the early machines used simple hardware operations 
such as "move byte” and ”add integer" which manipulated 
hardward-reco?ni z ed data types such as bytes and integers. 

As technology progressed and computer hardware gained 
functionality, more complicated operations sucn as floating 
point were moved into hardware, which substantially 
increases tne speed of tnese operations. Enhancement of 
standard programming methods as well as guaranteed 
enforcement of data protection were additional benefits 
derived from moving software functions into hardware. 

Recognizing that continued advancements in architectural 
enhancement would result in more data structures being moved 
into hardware, designers developed a methodology for viewing 
these abstractions that would contribute to tne concept of 
raising the level of hardware/software interface. One such 
methodology tnat integrates data abstraction, domain based 
protection, and nigh level system functionality is tne 



Ob jec t 


oriented m 


ethodology . 






The 


concept 


of using objects can be 


0 bserved. 


as long 


ago as 


1960, in 


LISP, Where atoms have 


prope r ti es 


that can 



22 



be related to real world objects. SIMULA, an extension of 
AL50L intended for simulation, included tbe idea of 
internally represented objects as Instances of classes. In 
an effort to produce a proeramminff vehicle that would reduce 
tne man-macnine semantic gap, Alan Kay, wnile still a 
graduate student at tfie University of Utah, investigated 
simulation and graphics oriented programming languages. 
Taiing many of his ideas, sucn as classes and objects, from 
SIMULA, Kay helped design the language FLEX. Continued 
refinement of FLEX carried tne object oriented paradigm to a 
smoother model by incorporating ideas from LOGO, a language 
designed to teacn programming concepts to cnildren, and 



resulted 


in the 


Smalltalk programming system. 




An 


object i 


s an abstraction that is usually 


considered 


to nave 


the foil 


owing characteristics: 




1 . 


0 b ject s 


are temporal; they exist in time; 




2. 


objects 

state; 


are mutable (subject to change). 


and have a 


3. 


objects 


can be created and destroyed; 




4. 


object s 


are particular (distinct), a 


nd can be 




shared . 


[Ref. 6] 





In general objects are similar to packages in that an object 
is a data structure that contains Information in an 
organized manner. Including a set of basic operations tnat 
directly manipulate the data structure. It can be referenced 
as one entity and has a label that tells its type. 
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As Kay continued his concept development throughout the 
1970'St tne idea of using an object oriented metnodoiogy to 
model complex real world issues be^an to emerge. IBM uses 
object oriented design concepts for complex projects. Grady 
Booch, formally of tne USAF Academy, advocates an object 
oriented design using Ada to enforce a clear design 
structure. Just as Smalltalk had used objects to represent a 
desired level of abstraction, object-based architecture was 
selected to model the growins hardware complexities. 

Based on an integrated approach to data abstraction and 
domain-based protection, object oriented architecture 
includes a form of capability based addressing and supports 
hiffh level system functions such as memory management, 
process management, and processor management. Because the 
architecture is rooted in data aostraction, good software 
design methodology is encouraged which will result in 
software systems tnat will be more reliable and nave reduced 
software life cycle cost. Elements of object-oriented 
architecture include: 



1. Objects for system management and control. 

2. Objects for program environments, flow of control, 
and intercommunication. 

3. Facilities for user object extensions and system 
object type manasement. 

4. Object addressing and protection mechanisms. 

5. An instruction interface. [Ref. 7J 
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System management objects include processor objects, 
process objects and resource objects. While a processor 
object is a memory based data structure, process objects 
represent a unit of computational wort for tne processor and 
contain information regarding scheduling and dispatching. 
Various resource objects are queue-iise structures used to 
bind physical processors with ready-to-run processes. By 
representing all resources as objects, a uniform interface 
for all system functions is obtained. 

Environment and control objects include data objects, 
instruction objects, domain objects, context objects and 
control linlc objects, while communication objects consist of 
message and port objects. Port objects are asyncnronous 
communication pathways between processes and provide for the 
queueing of waiting messages as well as resolution of speed 
disparity between concurrent activities in the system. An 
object oriented architecture with a built in software 
methodology should include support for representing typing, 
type manager packaging, and object authentication and 
creation. Object addressing and protection mechanisms are 
required to support references, mapping and protection. 
Finally, the object oriented instruction interface provides 
a uniform interface with uniform referencing to all tne 
object based facilities. 

A system environment can be viewed as a single set of 
objects which are addressable by everyone. Ranging from the 
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primitive storage segment naving ail tne cnaracteristlcs of 
a von Neumann store, to an abstract entity wnose physical 
form is hidden by tne architecture and wnose meaning is 
defined solely by the transformations that can be performed 
on it, objects provide still more protection by 
encapsulating data and program modules in a structure with 
not only well defined external visibility but carefully 
hidden internal structure. 

In summary, object oriented architectures were adapted 
to model the wide variety of hardware and software 
constructs that have been developed to enhance computer 
systems efficiency and reliability. In addition to raising 
the level at which the transition from hardware to software 
occurs, object oriented architecture enjoys technology 
Independent design through its information hiding structures 
and supports a variety of language structures including 
operating systems and reliable low life cycle cost 
applications software. For these reasons, Intel Corporation 
has chosen the object-oriented architecture as the 
predominant construct of the iAPX 432. 
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III. INTEL 432/670 SYSTEM DESCRIPTION 
AND“C0MP0NENT ARCHITECTURE 



TMs chapter will prese 
advantages of the 1APX432 
microcomputers. Additionally, 
oriented architecture will be 
form. 



n 



t the characteristics and 
over the conventional 
the concepts of object 
presented in a simplified 



A. THE 432 OBJECT ORIENTED ARCHITECTURE 

In an effort to find a solution to the software crisis 
While providing transparent multiprocessing, tne Intel 432 
designers' principal desire was to provide direct execution 
time support for both data abstraction and domain-based 
operating systems. Recognizing that both of the objectives 
could be supported by the object model, Intel selected the 
object oriented architecture as tne principal design 
construct to support a software methodology. This 
architecture provides mechanisms to help tne programmer 
follow the object oriented methodology. 

1 • Methodology 

Vnat does object oriented methodology mean? One of 
the best ways to modularize programs is by using the 
principle of information hiding as defined by D. L. Parnas. 
The basic idea is that a module should contain a collection 
of related procedures and associated data structures on 
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3 



wnicn tney operate. Procedures outside tne module snouid not 
nave access to ttie implementation details inside the module. 
The data can be referenced from outside tne module only by a 
call to one of the procedures inside the module. 

Modules that result wnen this principle is applied are 
referred to as abstract data types, extended types, or 
Parnas modules. Intel refers to tnem as type managers. 

At the same time that proerammine lan^uasres research was 
focusing on the concept of a type manager as the solution 
to the modularization problem, operaline system research was 
defining a very similar structure, the protection domain, 
as the solution to the security problem. Since operating 
system personnel were concerned more with security than 
modularization, they concentrated on the data in these 
domains, rather than the procedures which were the focus of 
the language research. Assigning the name "objects” to tne 
data items associated with domains, operating systems 
personnel called the whole information hiding methodology 
object either tne oriented meinodology or tne object model. 

Although experimental studies have demonstrated that 
objects are superb models for modern software systems, the 
overhead required to maintain the model is too excessive to 
permit efficient implementation without direct hardware 
support. [Ref. B.] The Intel 432 has hardware mechanisms 
that permit recognition of the following objects: 



28 



1. Processor 

2. Processes 

3. Dispalcbiiiff ports 

4. Interprocess messages 

5. Domains 

6. Context 

7. Instruction 
B. Data 



to permit an effective management of tne system's 
configuration and its individual resources as well as 
support for data abstraction. 



B. INTEL 4:32/670 SYSTEM 

Utilizing tne advanced arcnitecture of tne iAPX 432 
Micromainframe VLSI computer, the 432 family presents a new 
arcnitecture in tne world of microcomputers wnicn contains 
the following salient characteristics. 



1. Part of the operating system is contained in silicon 
and it is called The Silicon OS. It supports 
process scheduling, interprocess communication and 
dynamic storage allocation. 

2. Tne system operates in both single processor and 
multiprocessor conf i eura tions and it can include up 
to eignt (8) processors, altnougn tne 432/670 system 
can only support five (5) processors as limited by 
tne number of slots available in tne motner board. 
If one processor fails, the rest of the 
system can usually continue to operate. 

3. Hardware recognition of eight (8) data types. 

4. Hardware control functions for 16 ana 32 bit 
multiply, divide, and remainder operations. 

5. Hardwired control functions for 32, 64, and 80 

bit floating point arithmetic. 

5. Hardwired error correction and code protection. 

7. Object oriented desien. 
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9. Boia abstract data types and objects are supported 
by Hardware recognized, Hardware protected ana 
hardware manipulated structures. 

9. It Has an extremely large virtual address space 
bytes) and hardware supplied mechanisms for 
implementing virtual memory systems that can 
exploit this address space. 



The 432/670 system consists of tne three (3) subsystems 



1. Memory subsystem. \ Central System 

2. Processor subsystem. / 

3. Peripheral subsystem. 



and two busses: 



1. System bus bacJcplane. 

2. Multibus bacitplane. 



Before analyzing each one tne subsystems, tne following 
observations of tne systems architecture are germane: 
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unauthorized accesses but the peripheral subsystem may or 
may not provide protection. 
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Figure 3.1 General 432/670 System Orsanization. 



Figure 3.2 Illustrates a nypotnetical configuration tnat 
employs two peripheral subsystems. The main system's 
hardware is composed of two GDPs and a common memory that is 
snared by these processors. Tne main system's software is a 
collection of one or more processes that execute on the 
GDP(s ) . 



i/ol — 





/ 


1 general j 


\ 






!i/o| 


/ 


1 data 1 


\ 


... 




— 


/ 


i processor! 


\ 1 


i/o 1 




I 


/ 


\ / 


\ 


... 




. 1 

1 — — 


-/ 


T T 

1 1 


\— 


. * 

1 




1 per. 


jinterfacej main [interface i 


per. j 


... 


1 — 1 subs 


inrocessorlmemorylprocessor | 


subs j - 


- 1 i /o 


^ 1 

I 


A 


1 1 


/-- 


. 1 .. 
1 


... 


1 

1 


\ 


/ \ 


/ 


I 




... 


\ 


1 general | 


/ 


— 




li/oi 


\ 


1 data I 


/ 1 


i/o 1 




... 


\ 


1 procecor j 


/ 


... 




Figure 3 


.2 Main 


System and Peripheral 


Subsystem . 



31 



Vftien ttie salient characteristics of the 432 are vieweh 



with respect to tne levels of architecture within a 
computing system cited by Meyers [Ref. 9], it becomes clear 
that functions have been moved from both high level 
lanffuase and operating system to the hardware which raise 
the boundary line between hardware and software closer to 
the end user. Figure 3.3 illustrates the hardware-software 
Interface . 



iAPX 423 mainframe 
mini computer 
microcomputer 

Figure 3.3 Hardware - Software Interface 

Appendix A gives a comparison of tne IAPX 432 

architecture and tne architecture of tne conventional 

mai nf rames . 

1 ‘ Central Sys tern 

Tne central system consists of tne memory and tne 
processor subsystems. 

a. Memory Subsystem 

The memory subsystem resides on tne system bus 
bacsplane and consists of: 



applications 

nigh level 
language 

operating system 

basic instruction 
se t 



gate level etc 
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1 

2 

3 



One memory controller (MC) board. 

One to Ten Storage Array (SA) boards. 
A Memory Interleave (option). 



(1) Memory Controller Board. Tne memory 
addressed by tae 432 is organized in eignt-bit bytes. In 
spite of this Intel says that the 432 is a 32 bit 
microprocessor and that it can perform 32, 64, and 80 bit 
floating point arithmetic because with any read request from 
the system pro ces so r ( s ) , an additional signal determines now 
many bytes should be addressed. Tnls is called byte 
addressability. Thus, based on the processor(s) requests a 
word can consist of 1, 2, 4, 8, or 10 bytes and consequently 
8, 16, 32, 48, 64, or 80 bits can be addressed. 

(2) Storage Array 12. ill* Eacn Storage Array 
(SA) board contains 256K 8 bit bytes of memory. A memory 
controller can control up to 16 SA's or 4.096 Megabytes of 
memory. However, in tne current 432/670 systems . tnere are 
only 10 slots available for SA boards. 

Although tne 432 is a 32 bit microprocessor 
tne words are organized in 39 bit wide bantts. Tne seven (7) 
additional bits contain Error Correction Code (ECD) for eacn 
32 bit word. Tnis is controlled by logic existing on every 
SA board for generating, checking and storing this ECD. 
Finally, tne SA boards are organized in 645 byte banKs of 32 
bit words, four bytes per word. 



selected 



(3) Interleave Option. Tnis option 
by setting tne Jumpers of tne MC board 



can be 
to tne 
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proper position. Tne interleave option is available to 
ennance system performance. The interleave concept uses two 
banks of memory with alternating addresses to provide faster 
data access by overlapping memory operations. If tne 
interleave option has been selected, SA boards must be 
installed in pairs to provide tne alternate banjts. 

b. Processor Subsystem 

The processor subsytem, wnicn resides on the 
system bus backplane and consists of tne GDP and IP boards, 
is discussed under component architecture. 

c. Peripheral Subsystem 

The peripheral subsystems are discussed in the 
Basic I/O Model and Windows sections. 

C. COMPONSNENT ARCHITECTURE 

In this section, the basic architecture, of the major 
components of tne system ( GDP and IP) are presented. 

1 • A rc hitecture 

The 432 GDP consists of two chips the instruction 
decoder/microinstruction sequencer-43201 and the execution 
unit-43202. Appendix B contains the pin description of each 
Chip wnile Figures 3.4, and 3.5 show the block diagrams of 
the 43201 and 43202 chips respectively. 

In general, the GDP is organized internally as a 
three-staee microprogram-controlled pipeline. The first 
stage is the instruction decoder (ID), the microinstruction 
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sequencer (MS) is contained in tne second stage wnile tne 
tnird stage nouses tne execution unit. 

The first two stages of the pipeline are physically 
located on tne 432431 cnip (Figure 3.4), wnile tne tnird 

stage is the only function of tne 43202 chip (Figure 3.5). 
Actually each stage of tne pipeline is an independent 
subprocessor, wnicn operates until tne pipeline is full and 
then halts and waits for additional worK. 
a. Instruction Decoder 

Tne first subprocessor of tne pipeline is 
the Instuction Decoder (ID), which performs the following 
functions : 

1. Receives macroinstructions. 

2. Processes variable length ields. 

3. Extracts logical addresses. 

4. Generates starting addresses for micro- 
instruction procedures 

5. Generates micro-instructions for simple 
operations. 

The general tasic facing the Instruction 

Decoder is to interpret the macro-instruction stream, to 

determine wnicn micro-instruction sequence should be 

initiated next and to extract logical address data. 

Additionally, the Instruction Decoder provides a mechanism 
to recover from an instruction that faults. Tne information 
necessary for fault recovery is retained by the Instruction 
Decoder until the instruction is successfully completed. 
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Figure 3.4 43ii01 BiocJc Diagram, 



b. Microinstruction Sequencer 

Tne second subprocessor in tne pipeline is 
tne Microinstruction Sequencer (MS). Tne role of tne 
Microinstruction Sequencer is to decide wnicn 
microinstruction snould be sent to tne Execution Unit for 
eacn cycle. 
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c . lie culi on Onii 

The 43202 contains the Execution Unit' (EU) 
which is third stage of the GDP pipeline. This unit receives 
microinstructions from the 43201 and routes them to one of 
the two independent subprocessors that mate up the SU, the 
Data Manipulation Unit (DMQ) or the Reference Generation 
Unit (RGO). 
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Figure 3.5 43202 Bloci: Diagram. 
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operaiions. Additionally it contains tne control functions 
for 32, 64f and 80 bit floating point arithmetic. 

The Reference Generation Unit provides the 
translation of a 40 bit virtual address into a 24 bit 
physical address, a hardware enforced domain protection 
system (read, write, alter, accessed), handling sequencing 
for 8, 16, 32, 64, and 80 bit memory accesses, and 

controling tne on-cnip top-of-stacic register. In general, 
the Execution Unit manipulates data and translates tne 
logical addresses into physical addresses. 



d. Processor Pacfcet Bus Definition 
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with 



the same 



different oDJects located in main memory, 
protection mecnanisms as any iAPX 432 processor. Figure 3.6 
illustrates the internal architecture of the Interface 
Processor . 
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Figure 3,6 Interface Processor Bloclc Diagram. 



D. DATA MANIPULATION 

1 • ga rdwarg Recognized Data Typgs 

Computers store data in their memory in terms of 
zeros and ones. What these strings of bits represent depends 
upon the interpretation given to them by the computer. This 
means tnat two or more different pieces of information mlgnt 
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be represented by exactly the same strine- of bits and so 
this string could be Interperated as an Instruction, 
Integer, or character. These basic representations are 
called hardware recognized data types and nave the following 
characteristics : 



1. Each Instance of a type Is an addressable unit 
of memory. 

2, Each type has associated with It a set of 
operations that can be performed on this type. 



The combination of all the hardware recognized data 
types with all the operators which act upon them constitute 
the Instruction set of the computer. These hardware 
recognized data types are called primitive data types 
because they are used to construct more complex data 
structures . 

The Intel 432 recognizes eight different primitive 
data types, which are divided Into four classest Characters, 
Ordinal (unsigned integers 16 and 32 bits long), Integer and 
Real. Figure 3.7 provides the formats of each of tne eight 
hardware recognized data types [Ref. 15]. 

2 • Structured Data T^pes 

The term structured data types is used for ordered 
segregates of primitives. The two structured data types that 
can be accessed by the 432 are Arrays and Records. Although 
not supported by hardware, the 432 provides a mechanism that 
allows structured data types to be manipulated easily. 
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Figure 3.7 Primitive Data Types. 
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3 . Instructions 

The instruction set of me 43H is rich and supports 
five out of tne six operations wnich, according to Myers 
[Ref. 10], a language directed architecure must provide. It 
supports siring processing, arithmetic operations, program 
flov, error handling, and program tracing, wnile it is 
missing the editing operation. In addition, it supports 
segment and object creation. A summary of tne 432 
instruction set is contained in Myers [Ref. 11]. 

4 . I ^tru cjc i on Format 

The instruction formal of the 432 has four fields. 
The first field (class) specifies now many operands are in 
the instruction. The second (format) specifies now me 
operands are to be accessed. The third (reference) specifies 
tne logical addresses of up to three operands. Finally, toe 
fourth field (operator code) specifies tne operator. The 
segment selector identifies tne segment that contains the 
operand, while the displacement locates the operand within 
tne segment. Figure 3.3 illustrates tne instuciion format. 

3 • Addressing Modes 

The base and index values are used to locate the 
operand wiinln tne segment eitner by containing tne value 
itself (direct addressing) or by pointing to a location 
wnicn in turn points to tne location where tne value of tne 
operand has been stored (indirect addressing). 
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Figure 3.B iAPX 432 Instruction Format (tnree operands) 

A number of combinations {base direct/indirect and 
index direct/indirect) of direct and indirect reference are 
called addressing modes. The system selects tne most 
efficient v<ay for addressing tne various data types as 
follows ; 

1. Base and Index Direct : used to access scalars. 

2. Base Indirect, Index Direct : used to access 

records . 

3. Base Direct, Index Indirect : used to access 

static arrays. 

4. Base and Index Indirect ; used to access dynamic 
arrays . 

Figures 3.9A and 3. 95 illustrate tne four addressing modes. 
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Scalar: Index and Base Specified Directly 
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Record: Base Specified Indirectly 
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Figure 3.9A Addressing diodes 
® • Oper a nd S tact 

A special data segment maintained By tne Hardware 
for expression evaluation is called tne operand stacA. 
Accesses to tne top of tne operand stacK are called implicit 
references and tne items are added to or removed from tne 
stactt on a last-in first-out (LIFO) policy. Tne current 
stacA top is pointed to by a Hardware maintained stacA 
poi nter . 
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Static Array: Index Specified Indirectly 
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Dynamic Array: Base and Index Specified Indirectly 
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• iSiiru c t i on Encoding 

An effort das been to speed up execution ttirougn 
instruction decodine. A large percentage of a corrputer's 
time is spent fetching instructions; hence the faster the 
instuctions can be fetched the less time will be spent 
waiting to execute an instruction. 

The 432 uses bit-variable instructions versus the 
fixed-size length which is used by most machines. This 
flexibility implies that there is no constraint for the 
instructions to start or to end on byte or word boundaries. 
The size of the Instructions varies from 6-bit long for the 
shortest up to 344 bits lon^ for the longest instruction. 
Anotner difference, in the instruction encoding, is that in 
Instructions llte A = A -t- B, the operand A need to be 
referenced only once since the format field in the 

instruction indicates now many times a particular operand is 
used . 
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to addresses. Since tftere are 
numbers produced by tne decoder, 
linearly. However, if you loo 
point of view, a memory is said 
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1. Linear if the user can 

2. Segmented if tne user 
linear address, where 
segment . 



address it linearly. 

can address olcclrs of 
each space is called a 



Each item within a segment is addressed by a two 
component address: 

1. The segment selector which specifies the seement. 

2. The displacement which specifies the offset from 
the base of the segment to the item being selected. 



1 . MaSEi ng Segme nt ed Me mo ry 

In general, mapping is performed via the segment 
discriptors that are maintained in the segment table. Each 
segment has a corresponding segment descriptor which 
contains the starting physical address and the length of the 
segment. This mapping is illustrated in Figure 3.10. 

The segment selector of a logical address is 
used as an index to select a segment descriptor in the 
segment table. The displacement is added to the segment 
starting address to produce tne physical address of 
tne operand being referenced. Additionally, displacement 
is easily checKed by the hardware to ensure that the 
reference does not exceed tne length of the segment. 
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Figure 3.10 Segmented Mapped Memory. 



2 • Structured Memory 



Tne Intel 432 nas segmented memory wnicn is 
different from tne segmented memories of otner 
microcomputers as follows: 

1. Tne Intel 432 can address up to 2=*‘”‘24 segments. 
Sacn segment can be up to 2’=‘’*‘16 bytes long. 
Tnerefore, tne total virtual address space is 
2’!‘=^40 bytes. 

2. Tne Intel 432 uses a two-step mapping process 
tnat separates segment relocation and access 
control . 



For these reasons Intel refers to tne 432's memory as 
structured memory. 



Two-Step Mapping: The access mapping, being similar 



to one— step segment mapping process, is illustrated in 
Figure 3.11 and it is performed as follows: 
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1. The segment selector part of a ioeicai adnress 
Is used as an index Into tne access segment to 
select one of tne access descriptors, wcicn 
contain access riehts data. 

2. Tne access descriptor then acts as an index into 

the segment table to select a segment 

descriptor. 

3. The displacement is added to the segment 

starting address . 



Although .there are several segment types, the two 



fundamental types, called base types, are tne data segments 



which contain both data and instructions, and the access 
segments, which contain only access descriptors. Each base 
type is divided into several hardware recognized system .pa 
types. For example, data segments are aivided into 
instruction segments and stacK segments. 
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Figure 3.11 Two-Step Mapping, 
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Since two-step mapping process separates segment 
relocation from access control, tne type information is 
contained in the segment descriptor while the access 
information is contained in the access descriptor. This 
organization allows tne division of protection into user- 
specific protection (access rights) and segment-specific 
protection (segment type protection). 

Each program module is supplied at run-time with a 
collection of segment numbers for only those segments it 
needs to access during execution. These segments determine 
the access environment and they are stored in a collection 
of access segments. 

The advantages one can view in the two-step-mapping 
can be summarized as follows: 



the 
malnt 
segrre 
of a 



1. It taKes fewer bits in an address to specify a 
segment (as few as four bits). 

2. It restricts tne number of segments accessible 
by a given program. 

3. It separates the protection features into access 
and type protection. 

One potential problem with the two-step mapping is 
access time. To speed up tne process, Intel 
ains an associative cache that stores recently used 
nt descriptors, access descriptors, and tne addresses 
number of commonly accessed items. 
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^ §Qd Prot ec tion 

In eltHer me single or tne multiuser 
environment objects need protection from tne user wno mignt 
inadvertently use an object in a way tnat it was not 
intended to be used and from programs that mignt destroy tne 
object. Additionally, in a multiuser environment wnen 
several users require simultaneous access to tne same 
object, at least two more problems can arise: 



1 . 



Access Ri^nts: Not all tne users need to nave 

tne same access rignts. 



2 . 



Exclusive access: One user may 

exclusive access to tnat object for a 

operation to ensure tnat no otner 
alters tne object wnile tne operation 



require 
particular 
processor 
proceeds . 



These problems are solved in the 432 architecture by 
tne use of tne access descriptors. 

^ • Access 2£sc ri ptprs 

Each object nas its own access descriptors wnicn 
act as botn priviiedge and protection permits for the 
object. Many access descriptors can exist for the same 
object. Each access descriptor belones to some (but may be 
copied and/or passed to another) procedure (context), and 
defines the access rights of the procedure using this 
object. A procedure can reference a segment of memory if and 
only if it holds an access descriptor for that segment. Tne 
basic rights accorded the procedure by the access descriptor 
can be read only, write only, botn or none. 
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5* Segme^s versus Objects 

An object can be a contiguous subsection of a 
segment or it can consist of a single segment, or collection 
of segments. Figure 3.12 illustrates tne relation between 
segments and objects. 

Tne term segment refers to tne physical 
structure of tne data in memory while tne term object refers 
to tne logical structure of tne data in memory. Viewing an 
object as a single entity, its root segment specifies tne 
beginning of the object while the descriptor segment that 
points to this root segment is considered as pointing to tne 
whole object. Such a segment descriptor is called ooject .pa 
reference, while tne segment table containing object 
references is called object table. 



I ! seg- ! 

1 1 ment j 

1 0 B J S C 

! ! seg- j 

1 ment ! 

Figure 3.12 Relation among Objects and Segments. 

F. OPERATING SYSTEM 

Tne unique item in tne 432 arcltecture is tne way 

its operating system is implemented. There are two distinct. 



seg- ! 
ment I 
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* m 

m, . 






not self-compieie but cooperating, operating systems; one is 
implemented in nardware and is called tne Silicon OS, -wnile 
tde otner is a collection of Ada pacitages available to tne 
user for furtner modification as required, and called tne 

IMAX OS, Figure 3.13 illustrates the mecnanisms Implemented 
in tne Silicon OS and tne cooperating iMAX OS as well as tne 
conventional arcnitecture level and tne user interface 
level . 
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CONVENTIONAL ARCHITECTURE 
Figure 3.13 Silicon and iMAX OS's. 



Ilie Silicon OS 

A number of resource manaffement mecnanisms are 
Implemented in tne nardware, wnile tne resource managment 
policies are establisned by software in IMAX OS. Tnese 
mecnanisms are wnat Intel calls tne Silicon OS, wnicn 
consists of a memory resources manager and processor 
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resources manager. Tne mecnanlsms supported by tne Silicon 
OS are illustrated in figure 3.13. 

2 . iMAX OS 

The iMAX OS is a collection of Ada pacta^es provided 
in two different subsystems. Tne users can select tne one 
best tailored to their applications: 



a. Full IMAX provides run-time support including 
dynamic storage management, dynamic process 
manaeement, and I/O interface. 

b. Minimal iMAX is a subset of full IMAX and 
supports the execution of multiple processes 
on a multiprocessor environment. It does not 
support dynamic storage and/or process 
management and I/O except through the DEBUG- 
432 debugger. 



Tne only compiler that generates code for tne 
432 is the Ada compiler provided by Intel. Although this 
forces programmers to use only tne Ada language for writing 
programs running under tne 432, it allows them to mate easy 
calls to the iMAX packages by using the Ada provided 
facilities, sucn as tne environment pragma, witn clause and 
use clause. 

Two ttinds of processes can be controlled by IMAX; 
the static processes which are created by the user at 
system initialization and tne dynamic processes which are 
created dynamically by the system and then entered into the 
ready state. The minimal iMAX, which does not support 
dynamic operations, requires only 47K of memory compared to 
290S for the full iMAX. 
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Tlie IMAX paclcaffes manage and enhance the 4=;52'5 
interprocess communication, data transfers between 
peripheral devices and the 432 central system, and allows 
the users to configure and control a number of General Data 
Processors and Interface Processors, static user processes, 
and I/O device interfaces. 

G. PROGRAM STRUCTURE 

In most computer systems program structure is part of 
the operating system or tne language run-time environment 
and there is no need for tne program structure to be 
included in tne description of tne architecture. However, in 
the Intel 432, the program structure is part of the 
arcnitecture and contains tne following objects: 

1. Processor Objects 

2. Process Objects 

3. Context Objects 

4. Instruction Objects 

5. Data Objects 

1 • Proc es sor 0 b j,ec t 

A previous section specified that the processors in 
a multiprocessor environment are hardware-recognized 

objects and that object is a data structure in memory. It 
is logical therefore to asK how can a GDP, made of silicon 
and sitting on a pc board, where it fetches and executes 
instructions, be a data structure in memory? 

The physical processor is not an object. However, 
each physical processor does nave an object (a data 
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structure in memory) associated with it which is called a 
processor object. The processor object is an abstract 
representation of the GDP and is in one-to-one 
correspondence with the GDP. It can reside anywhere in the 
memory and can be dynamically relocated if necessary. 
Addressed by its associated processor via an on-cnip 
reference, the processor object provides the means to assign 
the processor it represents to a particular process set. It 
also serves to record information about the physical 
processor such as its state (running or halted), diagnostic 
information and references for other objects tne processor 
needs. Additionally, it contains an object reference for the 
process object currently running on the processor. Tnis 
reference changes in time as the processor switches among 
different processes. Tne processor object is depicted in 
Figure 3.14 with the operations which act upon it. 

Remember that the GDP is a three stage pipeline 
processor which consists of two chips, each one of which nas 
two subprocessors. If tne programmer tries to Iceep all of 
these details in mind as well as tne flow of information and 
the lata manipulation, while writing a program statement, 
complexity and confusion will reign. However, if the 
programmer considers that a processor exists which can 
perform a set of operations, programming is simpler. 
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2 • Pl 2 S§ss 0 1 j_ec 
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software (e.^. an operating systemK 

Figure 3.14 Processor Object. 



entity wnicn moves througa tne instructions of a procedure 
as the procedure is executed by the processor. Given this 
definition for a process object, now can a sequence of 
operations be an object? Tne process is not an object, out 
each process does have an object associated with it which is 
called a process object. Tne process object contains 
information concerning now the process should be scheduled 
and wnat is tne process status (running, waiting, etc.). 
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T&e sisnificance of tne existence and tne use or 
tne object reference is tnat tne 432's object oriented 
addressing and protection mecnanism does not ailorf a 
processor to access an object unless it has an object 
reference for it. Tne object reference from tne processor 
object to the process object changes dynamically in time as 
the processor switches among different processes. Each 
process has its own process object. The processes may snare 
the same processor. Figure 3.15 indicates operations on a 
process object. 



read process cloctc (ints) > 

enter global segment (inst) > 

get state information (hard) > 

save state information (hard) > 

dispatch process (hard) > 

set scheduling parameters (soft) > 

create process object (soft) > 



process 
0 bject 



Figure 3.15 Process Object. 



3. Context QbJ.ects 



several 



Procedures (e.g. SOOAREROOT 
different processes by giving 



X ) are snared among 
eacn process a copy 



(an instance) of the procedure. Each instance of a procedure 
(eacn copy) is called a context. 
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A context object contains information about a 
particular invocation of a procedure. Tnis means tnat tnere 
are as many context objects for tne same procedure as there 
are invocations of tne procedure. The information that a 
context contains includes the instruction pointer for tnis 
context, tne stactc pointer for this context's staclt, the 
return linK to the calling context, and references for all 
tne objects tnat can be accessed by tnis context. 

Jisure 3.16 depicts a context object and tne 
operations whicn act upon it. The complete list of objects 
currently accessible by tne procedure is called its access 
environment. The 432's object-oriented protection mecnanism 
does not allow a program to access an object unless it nas a 
reference for tnat object. Tnus in tne context one can only 
access objects that are listed in tne access environment, 
and tne access environment changes only if tne current 
context calls another procedure because tne called procedure 
nas a different context and nence a different list of 
objects tnat can be accessed. This places the protected 
access environment at tne procedure level, instead of tne 
process or Job level as on most systems. 

- • t i on 0 b j.e c t 

An instruction object nas two major 
characteristics: 

1. It can only hold instructions (and a little 
bit of system information) and never data. 
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2. It is tne only type of object tnat a 
processor will use as a source of 

instructions to be fetched and executed. 
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Figure 3.16 Context Object. 

This second feature implies tnat the 4:32's 
object-oriented protection mechanism will never allow any 
other kind of object (proccess object, data object, etc.) to 
be accidentally mistaken for instruction and thus executed. 
This isolation of tne instructions provides tne advantage 
that all 432 programs are fully reentrant. 

Instruction objects can be snared by several 
instances of a program. Figure 3.17 indicates an instruction 
object and tne operations wnicn act upon it. 

5 • Da ta Ob jects 

Data object is an object tnat holds data (e.g. 
integers, reals, character, tables, etc.). Tne 432 provides 
a mechanism for assigning lata objects (as well as other 
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objects) a software-defined type. Tnis is anotner protection 
mecbanism wtiicn ensures tnat tne object win oe manipulated 
by instructions of tne proper type. 
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Figure 3.17 Instruction Object. 



6. Summary of tne Structure of a Program 

Fiffure 3. IS summarizes tne important points 
about eacn object of tne program structure. 

H. INTERPROCESS COMMUNICATION 

It nas been said tnat one of the salient characteristics 
of the 432 is its capability to support multiprocessing in a 
multiprocessor environment. In other words tne system 
provides for concurrent programming. The mechanisms that 
support concurrent programming are quite complex and include 
the use of Communication Ports Objects, Domain Objects, and 
Dispatching Port Objects. Following an explanation of tnese 
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iProcessorT Pnyslcal Processor 

♦_ -Made of Silicon (not an ooject) 

I -Fetcnes and Executes Instructions 
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Processor object 

-Each processor has one 

-Contains information sucn as: 

-Processor status (es. running-, halted) 
-Diagnostic and macnine cnecK informat. 
-Reference for the process currently 
being executed 



Process Object 

-One for each process in tne system 
-Contains information such as: 

-Process status (eg, running, halted) 
-How tne process snould be scheduled 
-Reference for the context currently 
bein? executed 



I Context Object 

I -One per each instance of a procedure 
j -Contains information such as: 

1 -Instruction pointer for tnis object 
I -StacK pointer for this context's stacic 
I -Return linit to the context's stacK 
I -Reference for all tne objects that can 
I be accessed by this context 



Instruction Object 

-Contains only instruction and no data 
-It is the only type of object that a 
processor uses as a source of 
instructions to be fetched and 
executed 



The above 



are tne hardware recocnized objects 



I Data Object 

I” Data T ' -Contains Data (eg, integers, reals, 

I Object I I characters or a combination of several 
i primitive data types) 



Figure 3.18 Summary of the Proaram Structure. 
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objects, a simplified example will oe presentee for a 
general understanding of tne mecnanism tnat supports 
concurrent programming. 

1 . C om mu n ic a ti on Port 

A communication port is tne communication medium 
between two async&ronously communicating processes. Eacn 
communication port is represented by an object wnicn 
contains information on messages tnat are sent to processes. 
Figure 3.19 indicates operations on a communication port 
object. 
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Figure 3.19 Communication Port Object 
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The communlcallon ports, by acting as a buffer 
between two asynchronous processes, allow each process to 
proceed at its own rate. 

2 . Domain 0 b Je c t s 

Inbedded in the features of Domain Objects are the 
concepts of static and dynamic objects. Tne concept of 

dynamic objects has been already encountered in Section G.3, 
where the context objects are examined. Recall that the 
access environment consists of objects for wnicn an object 
reference exists in the list of the current context object. 
Additionally, tne access environment changes dynamically 
When a procedure is called by a context and the access 
environment is now the list of the new current context. 
Since the objects accessible by the process cnange 
dynamically in time, the objects pointed to by tne current 
context object vary in time. Therefore tne space they occupy 
in memory is deallocated once tney are not accessible by the 
proccess. Hence these objects are dynamic objects. In 

contrast static objects are those whose memory space is 

never deallocated regardless of whether they are accessible 
or not. In summary, a context object is also a list of 
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inignt consist of more tnan one procedure wnicn in turn mignt 
need to access some, all or none of the static oojects used 
by tne module. This is tne reason a domain contains a list 
of object references to ail static objects of the module, 

Tne reason objects associated with the modules 
are called domains is that tne module they represent confine 
knowledge of the object structure within a specified domain. 
Figure 3.20 depicts a domain object and tne operations wnicn 
act upon it. 
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Figure 3.20 Domain Object. 

NetworKs of domains, where each domain aides tne 
representation of an object, represent the static structure 
of a 432 program. Some of tne domains majce use of objects in 
other domains in the networic to create a more complex 

object . 

If a module (represented by a domain object) 

needs to use procedures provided by anotner module, tne 

first module must have a reference for the domain that 

represents the second module. The domains can be viewed 
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eittier from an outside or inside point of view. Consequently 
procedures can be executed inside or outside of tne domain, 
this prevents static objects of tfie domain from being 
accessed by ail procedures tnat use tnis domain. 

In this case tne static objects are divided as 

follows : 

1. Private objects - accessible only by 
procedures inside tne domain. 

2. Public objects - accessible by procedures 
both inside and outside tne domain. 

Let us assume the situation where a procedure 
(of a module) is currently executing. This procedure uses 
the same domain object which represents tne module tnat 
belongs to the procedure. In this case we say the procedure 
is executing inside tne domain. Tne same procedure needs to 
mafce a call to another procedure not belonging to its 
module. For tnis to be achieved tne first module must nave a 
reference to the domain representing the module of the 
callee. After this object reference is established tne 
caller can use the static objects only in the public domain 
of the callee. In this case the procedure is executing 
outside the domain. 

Pi spa tching Port Qbjecis 

Tne dispatching port object consist of two 
queues tnat serve to matcn processes with processors. It is 
the object that is used to implement transparent 
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multiprocessing. Figure 3.21 Indicates a dispatcnine port 
object and tne operations wnicn act upon it. 



Dispatcning port (nard) >! j 

! dispatcning 

Scneduie process (nard) >' I 

object j port j 

Enqueue processor (nard) >1 1 

object [ object [ 

Create dispatcning (soft) >1 I 

port 

Figure 3.21 Dispatcning Port Object 

4. Example of Int er process C om niunicatlon 

Consider a program, CHAT, wnich consists of two 
subprograms TED and JOHN. Program TED writes a report and 

tnen sends it to program JOHN to type it which in turn sends 

it baclc to TED for proofreading. Vnen tne report is correct 
TED prints it. 

Tne subprograms TED and JOHN will be tne two 
processes of CHAT wnich can start execution independently in 
two different processors of tne system. For simplicity let 
us consider tnat TED starts execution first and begins to 
write its report. Wnen it is finished, JOHN has been 

executing and it is ready to recieve TED's report for 

typi ng . 

The mechanism for sending the report from TED to 
JOHN is the communication port wnicn acts as a buffer 
between the two asynchronous processes, allowing each to 
proceed at its own rate. Two communications ports are needed 
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for our eiatnple. One is TED's receiver and JOKn's 
transmitter wnile tne otner is JOHN's receiver anc. TED'S 
transmitter. Figure 3.2H illustrates tne communication 
between TED and JOHN. 
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Figure 3.22 Interprocess Communication 



Tne processes TED and JOHN interchanee messases 
via tne communication ports and tne operations SEND and 
RECEIVE defined on tne communication port object bear tne 
burden of tnat intercommunication. 

Tne instruction SEND nas two operands. One is 
tne message itself and tne otner is tne communication port 
where the message is being sent. Before tne SEND is executed 
tne process nas a message it wants to send. After SEND is 
executed, the message nas been sent to tne specified 
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communica lioa port. For ef ficiencyt only the object 
reference is copied. 

The RECEIVE instruction has one operand, the 
communication port where the message is to be received. 
Before RECEIVE is executed there is a message waiting in the 
communication port. After RECEIVE is executed, tne message 
is moved from the port to the process executing the RECEIVE. 

Again only the object reference is copied. In tne case a 
RECEIVE instruction is executed without a message in tne 
communication port, the process waits until a message is 
sent . 

I. A BASIC I/O 'lODEL 

Another complicated mechanism in tne 432 arcnitecure is 
the I/O operation. Here we examine the basic means for 
performing an I/O operation as well as the very basic 
implementation mechanisms needed for I/O operations. 

A peripheral subsystem is an autonomous computer system 
with its own local memory, I/O devices and controllers, at 
least one processor, and software. The number of peripheral 
subsystems employed in any given application may be varied 
with changing needs, independent of the number of GDFs in 
tne system. 

To support tne transfer of data through tne wall that 
separates a peripheral subsystem from the main system, tne 
Interface Processor (IP) provides a set of software- 
controlled windows. A window is used to expose a single 
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object in main system memory so tnat its contents nay be 
transferred to or from tne peripnerai subsystem. 
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Figure 3.23 Peripnerai Subsystem Interface. 



The IP also provides a set of functions tnat are invosed 
by software. Tney generally permit objects in main system 
memory to be manipulated as entities, and enable 
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communication between main system processes and software 
executing in a peripheral subsystem. Figure 3.23 snows tne 
peripheral subsystem interface. 

A device interface is considered to be tne hardware and 
software in tne peripheral subsystem that is responsible for 
manaeinff an I/O device. A message sent from a process tnat 
needs an I/O service contains information that describes the 
requested operation (e.g. "read file XYZ”). The device 
interface interprets the message and carries out the 
operation. If an operation requests input data, the device 
interface returns the data as a message to the originating 
process. The device Interface may also return a message to 
positively acknowledge completion of a request. 

Tne IP is connected to the peripheral suosysiem bus as 
if it were a memory component; it occupies a block of memory 
addresses up to 64K bytes long. Figure 3.24 illustrates the 
peripheral subsystem hardware. 

The Attached Processor (AP) and tne IP interact with 
each other by means of address references generated by tne 
AP and interrupt requests generated by the IF. At any given 
time, the IP controller is represented in main memory by a 
process object and a context object. Like a GDP, the IP 
itself is represented by a processor object. 

¥hen supporting multiple process environments, the IP 
controller selects tne environment in wni cn a function is to 
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Figure 3.24 Peripneral Subsystem Hardware 



be executed. If an error occurs wMle tne IP controller is 
executing a function on benalf of one device interface, tnat 
error is confined to tbe associated process, and processes 
associated vitii other device interfaces are not affected. 

I. WINDOWS 

Svery transfer of data between tne main system and a 
peripneral subsystem is performed witn tne aid of an IP 
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window. A window defines a correspondence, or mapping, 
between a subrange of peripnerai subsystem memory addresses 
witbin the ranee of addresses occupied by tbe IP and an 
object in main system memory. 

Tbe action of tne IP, in mappine tbe peripheral 
subsystem address to tne main system object, is transparent 
to the aeent maKine the reference; as far as it is 
concerned, it is simply reading or writing local memory. 
Since a window is referenced liKe local memory, any 
individual transfer may be between an object and local 
memory, an object and a processor register, or an object and 
an I/O device. 

There are four IP windows that may be mapped into four 
different objects. The IP controller may alter the windows 
during execution to map different subranges and objects. A 
fifth window provides the IP controller with access to the 
IP's function facility. By writing operands and an opcode 
into predefined locations in this window's subrange, the IP 
controller requests the IP to execute a function on its 
behalf. Upon completion of the function, the IP provides 
status Information that the IP controller can read tnrough 
tne window. 

Since there is a finite number of windows, most 
applications will need to manage them as scarce resources 
that will not always be Instantly available. This means that 



73 




4 



I 



m 



at least some I/O device transfers will nave to be buffered 
in local memory until a window becomes available. 

L. TRANSPARENT MULTIPROCESSING 

Tfte Intel 432 is especially designed to support parallel 
execution of programs by multiple processors. Absolutely no 
software changes are required to move programs from single 
processor systems to multiple processor systems or vice 
versa . 

Tne first advantage of transparent multiprocessing is 
flexibility provided by a macnine tnat o fers a ran^e of 
performance. Processors can be added to or removed from 
tne configuration to meet tne desired performance or price. 
Tne second advantage is reliability, because if one 
processor fails, tne rest of tne system may be able to 
continue running. In fact, luring a bencnmaric performance 
test, one slot in tne system motnerboard prevented an 
assigned GDP from being initialized and tne system continued 
to execute. 



1 . Tne Tnree Stagey of. Processor Management 

Tne effective management of multiprocessing in a 
multiprocessor environment requires Policy Maiclng, 
Scneluling, and Dispatening. 

a. Policy Malting 

Policy Maxing establisnes tne criteria tnat 
determines bow processes snare processors. These criteria 
are defined by tne user, via tne IMAX OS, at system's 
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initialization. The iMAX OS passes tnis information to tne 
Silicon OS for implementing tne policy mecnanism. 

Options tnat can be selected to implement 
processor snaring are first - come - first - serve (FIFO), 
round robin, priority, and deadline weignted. Tne user can 
select tne one which meets the applications reoui rements . 

The Policy MaJcing requires tne user to set 
the scheduling parameters by answering questions such as: By 
when must the process be completed? How long does a process 
execute on tne processor? flow many turns can a process nave 
before terminating? 

b. Scheduling 

Scheduling is tne ordering of processes to 
run on processors in a manner that realizes the policy. It 
is part of the mecnanism that carries out the policy. 

A process is scheduled by sending tne 
process to the lispatchine port in the form of a messase 
object. Once in tne queue, tne process waits for a processor 
for execution. 

c. Dispatching 

Dispatching is the assignment of processes 
to processors in the order in which the processes nave been 
scheduled . 

The meeting places for processors and 
processes are tne Dispatcing Ports where tne the processes 
stand in line waiting for service by a processor, and 
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processors go wben tney need 
a processor needs a process 
the first process in line at 
to execute it. 



a process to execute. Whenever 
to execute, it simply removes 
its dispatching port and begins 



2. Dis pa tcing and Progra.m St ructure 

We nave seen that the dispatching port objects are 
closely related to the processor object and process object 
which are part of the program structure. This relation must 
be well controlled in order to prevent perturbation of tne 
program structure. 

For example the networic required to perform process 
scheduling and dispatching is complex. To Keep tracK of 
these assignments two things must be accomplished. First, in 
each processor object there is a object reference for the 
processor's dispatching port, wnicn means that each 
processor has only one dispatching port. This information 
forces a processor to always visit tne same dispatching 
port. Second, in each process object there is an object 
reference to the dispatching port the process is allowed to 
visit and thus, a process can visit only one dispatcning 
port. We can conclude, therefore, that by naving one 
dispatcing port per processor and process tne 
multiprocessing tasK of the -132 can be accomplished without 
major effort other than assigning tne proper policy maKing 
parameters . 
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This chapter has presented the characteristics and 



advantages of tne Intel 432 over conventlnai 
microprocessors. Althoueh this chapter is lone and at times 
detailed, it presents the requisite information necessary to 
understand the results observed in the Benchmarx Performance 
Chapter , 
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MaLTiPROCESSOR/MOLTiPROCSSS BENCHMARK PERFORMANCE 



In general the Benchmartr Performance Test was conducted 
using the Benchmark programs generated in Applegate [Ref. 
3J t modified as required to execute in tne 
Multiprocessor/Multiprocess environment. Initially, the test 
was conducted with only one processor and one process in tne 
system to confirm the results reported In Applegate [Ref. 
3J . Then, using the same BencnmarK Programs, tne test was 
performed with two processor/processes, three 
processor/processes and finally four processor/processes in 
the system to determine if the 432/57C system is capable of 
sustaining incremental performance improvements as 
processors are added to tne system. 

A. BENCHMARK PERFORMANCE TEST 

Kodres [Ref. 12j analyses multiprocessor systems that 
uses a common shared memory. Although dependent on the type 
of instructions being executed, it was snown that if tne 
programs are fetched from common memory, the systems bus 
becomes a bottleneclr with only two processors in tne system. 
To determine if the INTEL 432/670 system could be effective 
with six processors as reported in the Intel manual [Ref. 
13] , a series of Benchmarir performance tests were conducted 
using seven programs from the Computer Family Architecture 
Study (CFS) (Figures 4.1 - 4.4), two programs from a 
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performance comparison conducted by tne University of 
California - Bertceley (Figure 4.5), and two programs tnat 
executed instructions at opposite ends of ttie iAPX 432 bus 
activity spectrum (Figure 4.6). Ail Bencnmaric programs were 
executed witn the operating system configured for the 
default service period (DF) and again with the service 
period set to infinite period count (IFK Each figure 
depicting performance contains tne name of the Benchmark 
program, tne number of iterations, and tne number of seconds 
required to complete the execution as well as tne curve 
showing maximum theoretical efficiency, observed performance 
for the infinite period count (IF), and default (DF) service 
periods. Additionally, calculated efficiency numbers 
associated with each system configuration are included on 
the right side of the graph for easy reference. 

Each prosrram was executed witn tne INTEL 432/67iJ system 
configured for one processor. A second processor was 
installed and two processes containing identical Bencnmars 
programs were timed during execution. Processors and 
processes were added incrementially up to and including four 
IAPX 432 General Data Processors (GDP). In general the tests 
Show that tne INTEL 432/670 system was still performing at 
approximately ninety percent efficiency with four processors 
in the system. 
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B. RESULTS 

Since Kodres [Ref. 12J predicted serious bus contention 
at two processors and tbe observed performance is still at 
approximately ninety percent witn four processors in the 
system, additional analysis was performed using a Logic 
State Analyzer to observe systems bus activity wnile 
executing instructions at opposite ends of tne bus activity 
spectrum. Bencnmaric programs were designed and implemented 
tnat execute tne MOVCH instruction to represent tne nlgn end 
of bus use density and DIVORD to represent the low end of 
bus activity. 

Snoop [Ref. 14j , considering a system bus widtn of 
sixteen bits and a nlgn transfer speed, predicted tnat tne 
MOVCH instruction would taKe 10.4 microseconds to execute 
wnile the DIVORD would require 29.6 microseconds. Using the 
Logic State Analyzer delay function and triggering on a 
Known address, a series of program executions were performed 
to generate a bus activity snapshot of 650 microseconds. By 
counting the number of bus access cycles and tne number of 
execution cycles, tne relative efficiency of tne Intel 
432/570 computer system was calculated for one tnrougn S 
processors using the equation derived by Sodres [Ref. 12j : 
Figure 4.7 depicts tne predicted and experimental results 
for the liOVCE and DIVORD instructions. 
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Re = (B + fi) / (NB + I) w&ere Re = Relative efficiency 

B = Bus activity cycles 

E = Execution Cycles 

I = System's Bus lale 
Time 

N = Number of Processors 



To determine if tne lata gatnered during ttie Bus 
Snapsnot period was representative of tne BencnmarK 
performance executions, tne instruction execution times are 
compared in Table 4.1. Tnere is a small difference in 
execution times measured by tne bus activity snapsnot as 
opposed to timing tie repeated execution of tne instruction. 
Since tne timing is accurate to tne nearest second, tnis 
small difference can be attributed to measurement error. Tne 
larger difference between Snoop predicted execution times 
and measured execution times can be attributed to an overly 
optimistic prediction by Snoop. 

From tne calculations displayed in Figure 4.7, systems 
executing instructions consisting of MOVCH would begin to 
saturate tne system's bus at 4.3 processors wnile DIVORD 
instructions induce tne bottlenecK at 7.7 processors. Since 
tne execution time of DIVORD is greater tnan MOVCH, it 
follows tnat tne predicted bus contention snould be less for 
tne DIVORD program as observed. Since tnese instructions 
represent bus activity at opposite ends of tne bus activity 
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spectrum, It appears t&at tne Intel's design of six 
processors per system is an appropriate cnoice. 

C. ANALYSIS 

Tne explanation for tnis performance improvement over 
that observed in otner Multiprocessor/Multiprocess systems 
tnat fetcn programs from common memory is tne INTEL 432/670 
system nas a 32 bit system's bus. The 32 bit system's bus 
nas a maximum of 77 megabits per second transfer rate 
compared to about 12 megabits per second for a typical 16 
bit MULTIBUS system's bus. Additionally, tne instruction 
formats used by tne iAPX 432 processors are designed to 
reduce the number of bytes transferred. Finally, by usin^ a 
byte addressable boundary ratner tnan a word boundary, tne 
number of bytes that must be transferred wnen a processor 
fetches instructions is reduced. 
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Figure 4.1 CFA 3encnmaric CHAR Performance. 
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Figure 4.2 CFA BencnmarK QUICK Performance. 
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Figure 4.4 CFA Bencfimaric HASH Performance. 
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Figure 4.5 U. C. Berseley Bencnmars Performance. 
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Fleure 4:. 6 MAX/MIN Bus Activity BencUmanc Performance. 
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Figure 4.7 Preuected and Actual Processing Performance. 



Tatle 4.1 Instruction Execution Times (Microseconds). 



INSTROCTION 
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12.6 



10.4 
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32.3 



32.1 
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CONCLUSIONS 



The excessive execution overhead resultin? from ttie 
Intel 432 object oriented architecture has prevented tne 
Intel 432 from demonstrating superiority when comparin? its 
speed of execution to otner microprocessors in a 
Uniprocessor environment (ie., one processor with its own 
memory and systems bus). For example when compared with the 
Motorola 68200 and the INTEL 8086, the iAPX 432 provided 
approximately one-half the throughput [PATTERSONJ . 

BenchmarK performance depends heavily on tne Instruction 
set being executed. Since Individual systems use unique 
metnods of performing certain operations, average Bencnmarx 
fiffures could be misleading if the system was to be designed 
for a specific application. For example, if the instruction 
set required was predominately Floating Point operations, 
the INTEL 432 performance should be superior because of its 
efficient Floating Point hardware. 

'rfhen comparing a computer's ability to perform in a 
Multiprocessor environment, instruction mix is still 
important but you must also consider the bandwidth of the 
memory. There are tnree types of Multiprocessor 
architectures that effect the bandwidth characteristics of 
Multiprocessor systems: 



90 







■m 









m 













1. Proffram and data stored in Global memory wnere 
all processors nave equal access. 

2. Program stored in a local memory isolated to 
access only by tne parent processor. Data would 
be stored in global memory. 

3. Same as system 2 except local memories are also 

accessible by otner processors tnrougn a Crossbar 
Swi ten . 



The Crossbar Switch is a system tnat enables tne designer to 
increase the number of system buses to tne point wnere there 
is a separate patn available for each memory unit. Its 
obvious advantage is to eliminate the system bus contention 
when operating in a Multiprocessor/Mul tiprocess environment. 
Since many real-time applications programs reside in global 
memory, tne BencnmarK test were conducted in the global 
memory stored program environment. Processing power of a 
system of computers sharing a common systems bus, is 
measured in relative efficiency (see Chapter IV. B.). Each 
processor must be able to process tne program steps and data 
without interfering with eacn otner by saturating tne system 
bus with request for instruction and data fetches. 

Analysis of the INTEL 432/6745 system Benchmark 
performance test show that the relative efficiency of the 
system is still approximately 90 percent with four 
processors in tne system. Tne effectively maximum number of 
processors is confirmed at six. This is in sharp contrast to 
an effectively maximum of two processors for tne INTEL S086 
operating witn a MULTIBUS systems bus [KODRESJ . Again it is 
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empnaslzed tnat tnese performance figures are based on a 
common memory stored program system. 

Altdougn tdls tnesis was not concerned with transparent 
multiprocessing, the advantages of a system that supports 
this concept was evident. During BencnmarK program 
executions, a processor was prevented from being initialized 
due to a loose piece of plastic in the motherboard card edge 
connector. The system continued to function automatically 
sequencing the extra process into the dispatching queue. The 
actual failure was only discovered when attempting to 
determine a sudden increase in execution times. 

Benchmaric programs for this project were written in the 
Department of Defense programming language Ada. Previously 
generated code was found to be self-documenting, easy to 
modify, and interfacing problems were non-exl stant . Although 
Ada has been cited as a complex language, the ease with 
which it is modified combined with its strong typing 
characteristics, and readability confirms its ability to 
support the Software Engineering principles. 

While the effectively maximum number of processors for 
general purpose computing in the INTEL 432/670 system is 
comflrmed at six processors, incorporating the iAPX 432 into 
a Crossbar Switch system could produce a system capable of 
supporting up to 50 processors. Its direct military 
application to tactical systems requiring a growth potential 
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Is exciting parilcuiariy waen considering tne ability of tne 
lAPX 432 to support transparent multiprocessing. 

Since current Navy microcomputers sucn as tne AN/ATK-7 
cannot be expanded beyond four processors witnout reoulrin? 
major restructuring of tne existing software, it is 
recommended that a follow on study be conducted to determine 
if a large system is feasible using tne lAPX 432 in a 
Crossbar Switch system. 
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APPENDIX A 



iLll 132 VS CONVmiONAL MAINFRAMES 

This appendix provides a comparison of me iAPX 432 
Architecture and the Architecture of Conventional 
Mainframes . 



[Feature of Archit. 


{Convent. Mainfr 
{ Architecture 


{ iAPX 432 { 

{ Architecture { 


{MEMORY organization! 


1 1 
1 1 


1 Organization, size'Linear 


{Structured segmented! 




{2»^24-2’^^32 bytes 


{2’=‘^24 segments { 




1 

1 


{2^^16 byte { 




1 

1 


{ displacement { 


J 


1 

I 


[2’=‘^40 byte virtual { 


1 


1 

1 


1 address space | 


jLofficai to physi ca 1 1 Sinele-level map 

i 1 


{Two-level map { 

1 1 


1 1 

{address trans lation { Page-based reioc 


1 1 
{Segment-based reioc { 




{and virtual mernor 
1 


{and virtual memory { 
1 1 


{Protected memory 


1 

iFixed-size page 


{Individual program { 


{ uni t 


1 

1 


{module or data { 


1 


I 

1 


{structure { 


{DATA MANIPULATION 


I 

1 


1 1 
1 1 


! Expression 


{General register 


IStacK or memory-to- j 


! evaluation 


1 

1 

1 


Imemory ! 

1 1 


{Primitive data 


1 

1 Cbaracters » 


t t 

{Characters, unsigned! 


{ types 


1 unsigned integers 


{integers, integers, { 




1 integers t reals 


{reals, temporary { 




1 

1 


{reals { 


{Floating point 


,'les 


{Yes ! 


{ hardware 


1 

1 


1 1 

t 1 


{Addressing modes 


{Some modes not 


{Symmetrical: all { 




{available for ail 


{modes available for { 




{ operands 


{every operand { 


{PROGRAMMING 


1 


1 1 
1 1 


{ENVIRONMENT SUPPORT! 


1 1 

t ! 


{Operating system 


{No multi-process 


{Multi-process { 




{ support 


{mechanisms in ! 




1 

1 


{hardware { 




{No support for 


{Dynamic storage { 




{dynamic storage 


{allocation { 




{ alloctation 


{mechanisms in { 




1 

1 


{nardware { 
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iHign level language 

1 

I Programming 
Imet&odology 



Very limited mult I Software-transparent 
multi- processor 'multi-processor, 
operation if any loperaiion 



Assembly 
oriented 
instruction 



I 
I 

language j Oriented 



level 



set 



toward nign 
languages 



No support at all JObject-based 

larcbi tec ture 
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APPENDIX B 



PIN description 

THIS appendix provides me pin description of tne 
432 general data processor. 

43201 Pin Description, 

Processor PacKet Bus Group. 

ACD15-ACD0 (Address/Control/Data lines, Inputs, nign 

asserted ) , 

PRO (Processor Packet bus Request , Input, nign asserted), 
ICS (Interconnect Status, Input, nigh asserted). 
Intra-GDP Bus Group. 



aii5— 010 
asserted) . 


(Microinstruction Bus 


lines , 


Outputs , 


nign 


IS6 IS0 


(Intercnip Status 


lines , 


Inputs , 


nign 



asserted) . 



System Group 

FATAL/(Fatal , Output, low asserted). 
ALARM/(Aiarm signal , Input , low asserted). 
INIT/(Initialization, Input, low asserted). 
CLH/( Clear, Input , low asserted) 



Hardware Error 


De tec 


tion Grou 


P 


Mast 


er (Master 


, I n pu t 


,hign ass 


er ted ) 


HERR/(Hardware 


Er ro r 


, Output , 1 


ov ass 




Ciocic Group 






CLSA 


, CLKB (Cl 


OCK A, 


Cl OCK 3 , 


Input 




Testing I 


nput 






RDROM/(Read RD 


M , I npu 


t,low asserted) 




Power and 


Ground Connect 


ions . 


7CC 


(4 pins ) . 








GND 


(5 pins ) 








7BB 


( Internail 


y Gene 


rated ) . 




N .C , 


(No Conne 


cti on , 


4 pins) 





iAPX 
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43202 Pin Description 
Processor PacKet Bus Group 

PRO (Processor Pacset request, Tnree-state Output, ni^h 
a sserted ) . 

ICS (Interconnect Status, Input, High assertea). 

Bout (finable Buffers for Output, Output, nign asserted). 

Intra-GDP Bus Group. 

uI15-uI0 (Microinstruction Bus lines. Inputs, nign 
asserted) . 

IS6-IS0(Intercnip Status lines. Outputs, nign asserted). 
System Group 

PCLK/(Processor Clocic, Input, low asserted). 

CLR/(Clear, Input , low asserted). 

Hardware Error Detection Group. 

Master (Master, Input, nign asseredj 25 k nomonal pullup 
on-cnip ) . 

HERR/( Hardware Srror, Open Drain Output, low asserted). 
ClocS Group 

CLKA, CLKS (ClocK A, ClocK B, Inputs). 

Power and Ground Connections. 

7cc (Power Supply, 4 pins). 

GND (Ground, 5 pins). 

N.C. (No Connection, 7 pins). 
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APPENDIX C 



SAMPLE PROGRAM LISTING WITH SUBMIT PILES 



This 

generate 



appendix contains all the necessary 
Muiti proce s so r /Multi pro cesses environment 



files 



to 



CHARSUMSS 

— CEARSl pacicage specification 

— This is the ADA specification pacKa^e for the 

— CPA character search bencnmari. 

— CHARS 1 



pacicage SCHAR is 

subtype subint is integer range 1 
type titarray is a rray ( 1 . .256 ) of 
a rrayl ,a rray2 : titarray; 
procedure SEAHCH(srchien,arglen : 

a rrayl ,array2 

loc : 



end SCEAR; 



.256; 

Character ; 

IN subint; 

IN titarray; 
OUT integer); 



CHARSUMBS 

— CHARSl pac'sage body 



— Tne following package contains the procedures needed to 

— implement the CPA character search oenchmarK. Procedure 

— SEARCH performs tne actual searcn as desired by tne CPA. 

— CHARSl 



pragma environment("ACS:TEXTIO.MLE”,"lNTIO.MSE”, 

"S CHAR. MS E") ; 

with teit_i 0 , i nti o; use tex t_io , intio , ascii ; 
pacKage body SCEAR is 

procedure SEARCH ( s rcnlen ,arglen ; IN subint; 

arrayl , arrays : IN titarray; 

loc : OUT integer) is 
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tnen 



i,J : integer; 
besin 
i := i; 

J := i; 
loc := -i; 

wniie i <= srcnlen loop 
if arrayl(i) = array2(j) 
if J+1 <= arglen tnen 
i := i+i; 
j := j-^1? 
else 

loc := i-j; 
exit; 
end if; 
else 

1 := i+i; 

J := i; 
end if; 
end loop; 
end search; 
end SCHAR; 



PRlMAlNiMSS 

pacKage USER_PR0CESS_1 is 
procedure MAIN; 
end USER PROCESS i; 



PR2MAIN .MSS 



pacKage USER_PR0CESS_2 is 
procedure MAIN; 
end USER PROCESS 2; 



PR3MAIN^MSS 



pacKage USER_PR0CESS_3 is 
procedure MAIN; 
end USER PROCESS 3; 



PRiMAIN^M§.S 

package USER_PROCES S_'4 is 
procedure MAIN; 
end USER PROCESS 4; 
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PRIMAIN.MBS 



— CHARSl driver routine 



pragma envi ronmen t( "ACS :TEXTIO. MLE” , " INTIO.MSE” , "SCHAR .MSS 

"PRIMAIN.MSE"); 



witn text io ,intio, scharj use text io , intio ,scftar , ascii ; 
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— Timing also includes time for procedure 

— invocation 
3 May 1983 

package body USER_PR0CESS_1 is 
procedure MAIN is 

i ,loc ,srcn_lengtn,srcn_arg,timer_loop : integer; 
besin 



initialization 



arrayl :=(M,o»nfd.a,y,,, ,J,u 
e,7,t,n,,, ,1,9, 7, 6 

otners => 

array2 := ( 'd' , 'a' , 'y otners => ' '); 
srcn_leneth := 22; 
srcn_arg := 3; 
t imer_looT) := 1000iJt5; 

put 20(‘* Start of Searcn. . .l" ) ; 

putlSEL ) ; 

put ( BEL ) ; 

put ( BEL ) ; 

put ( BEL ) ; 

put ( BEL ) ; 

for i in 1.. timer_loop loop 

SEARCH ( srcn_lengtn7srcn_arg ,arrayl ,array42, loc W 
end loop; 

put 20("end the search l’); 

putlBEL ); 
put ( BEL ) ; 
put (BEL ) ; 
put(EEL ) ; 
put (BEL ); 
end main; 

end aSER PROCESS i; 



, n , 
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PR2MAINiMBS 

— CHARSl driver routine 



pragma environment ( "ACS : TEXT 10. MLB" , " INTI 0 .MSB" , "SCHAR .MSB" , 

"PR2MAIN.MSE"); 



witn teit_io ,intio, schar; use teit_io , intio , sonar ,asci 1 ; 



— Timing also includes time for procedure 

— invocation. 

3 may 1983 

package body USER_PR0CBSS_2 is 
procedure MAIN is 

i ,loc ,srcn_length ,src&_arg ,timer_io op: integer; 
begin 



initialization 



arrayl 




✓ 

a 

f 




array2 ;= ( 'd' , 'a' , 'y ' ,otners => 



srcn_lengtn := 22» 
srcn_arg := 3> 
timer_loo^ ;= 100000; 
put 20 (" Start of Searcii 
putlBEL ) ; 
put (BBL ) ; 



pu t ( EEL ) i 
put (BEL ); 
put ( BEL ) ; 



•* . 

2 ); 



'); 



otners => 



for i in 1.. timer_loop loop 

SSARCH( srcn_lengtn ,srcn_arg , arrayl , array 2, loc ) ; 
end loon; 

put 20("end tne searcn 2"); 

putlBBL ); 
put (BEL ) ; 
put ( BEL ) ; 
put (BEL ) ; 
put ( BEL ) ; 
end main; 

end USER PROCESS H; 






n 



f 



)i 
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PR3MAIN.MBS 



— CHARSl driver routine 



nras'ma environtnen t( "aCS:TEX?IO.MLE” »’*INTI0.MSE’*,"SCHAR.MSE 

’’PR3MAIN.MSE"); 



witn text_io ,intio, scnar; use iext_io , int io , scnar ,esci i ; 



Tilling also includes time for procedure 
— invocation. 

3 May 1983 

pactaee body USER_PR0CESS_3 is 
procedure MAIN is 

i ,loc ,srcn_lengtn ,srch_arg,timer_loop : integer? 
begin 



initialization 



arrayl :=(M,o,n,d,a,y 

f f f—f f * f f ^ f f 

et‘»ttb»*» 



'/J'/u' 
Others => 

')? 



arrays := ( 'd' , 'a', 'y' .others => 
srch_leneth := 22? 
srcn_arg := 3? 
timer_loop := 100000? 

put 20(" Start of Search .. ,3*’ ) ? 

putTSEL ) ? 

put (BEL ) ? 

put ( BEL ) ? 

put (BEL ) ? 

put(BEL)? 

for i in 1.. timer_loop loop 

SEARCH ( srcn_lengtn ,srcn_arg .array 1 . arrays. ioc) ? 
end loop? 

put 20("end the search 3")? 

putlBEL )? 
put(SEL )? 
put ( EEL ) ? 
put (BEL )? 
put (BEL ) ? 
end MAIN? 

end USER PROCESS 3? 



, n 

‘ ') 
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PR4MAIN.MBS 



— CHARSl driver routine 



praema environment( "ACS : TEXT 10. MLB” 

"PR4MAIN.MSE”); 

tfitn text_lo ,lntlo, sonar? use teit_ 



, " INT 1 0 . MS E ” , "S CHAR . MS E 
i 0 ♦ int io , sonar ,dsci 1 ? 



« 



— Timing also Inoludes time for prooedure 

— invooation. 

— 3 May 1983 

paolcage body 0SBR_PR0CBSS_4 is 
prooedure MAIN is 

i ,ioo.sron_lengtn , sron_arg ,timer_ioop : integer? 
forever : boolean :=true? 
answer : oharaoter? 

begin 



wnile forever loop 
■ initialization 



arrayl 






otners => 

arrays := ( 'd' , 'a 'y' , otners => ' " ) ? 
srcn_lenetn := 22? 
sron_arg := 3? 
timer_loop := 100000? 

put_20(" Start of Searon . . .4" ) ? 

put ( BEL ) } 

put ( BEL ) ? 

put (BEL )? 

pu t ( BEL ) f 

put (BEL ); 

for i in 1.. timer_loop loop 

SEARCH( srcn_lengtn , sron_arg, arrayl , arrays, loo ) ? 
end loop? 

-put_20( end tbe search 4”)? 

put (BEL ) ? 
pu t ( B EL ) ? 
put ( BEL ) ; 
put (BEL ) ? 
put (BEL ) ? 
forever := false? 



end loop? 
end main; 

end USER PROCESS 4? 



n , 



); 
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DFPSERPl.MBS 



Pragma environment( "ACS : BPfi , MLE" , " ACS : VlUSRP , MLI " , 

PR1MAIN.MSE"/PR2MAIN.MSE",”PR3MAIN.MSE","PR4I^AIN .MSE” ); 
with Process_Def ini tlons , iMAX_Def ini tions , 

Ba sic_Process_ma naeement ; 

with Oser_Process_l ,Oser_Process_2 ,User_Process_3 , 

Usir_Process_4; 

package body User_Processes is 

— Function: 

Tnis module instantiates tne user processes and 

— provides an initialize procedure which completes the 

— initialization of each user process. 

— For each user process, there is an instance of 

— iMAX_De f initi ons . proceiure_val which contains the 

— process' initial procedure. To minimize me size of 

— this package, the initial procedure here simply calls 

— tne actual initial procedure wnicn is found in 

— another module. For each process, there is also an 
instantiation of Process_Def ini tions . Process_Instance 

— which specifies the process id, the procedure_va 1 

— just mentioned, and tne process' stacjc SRO and object 
table sizes. 

— Finally, tne initialize procedure provided by tnis 

— module simply calls the 

— Complete_process_initialization procedure 

— in each instantiation of 

— Process Definl tions .Process Instance. 



procedure 

procedure 

procedure 

procedure 



prlmaln J 
pr2main ; 
pr3ma in » 
pr4main »* 



— SPECIFICATIONS FOR USER PROCESS 1 — 



package UPROCl is new Process_Def ini tions .Process_Instance 
( Process_S tartup => prlmain, 

SR0_slze »> 4000); 

•“ service_period => 

basic_process_management . inf ini te_perl od_count ) » 
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— SPECIFICATIONS FOR USSR PROCESS 2 — 



package UPR0C2 is new Process_Dei'ini tions .Process_Instance 
(Process_Startup => pr2main, 

SR0_size => 40430 ); 

— service_periol -> 

baslc_process_management . Infi ni te_period_count ) ; 



— SPECIFICATIONS FOR USER PROCESS 3 — 



package UPR0C3 is new Process_Definitions.Process_Instance 
(Process_Startup => pr3main, 

SRO_size => 4000); 

— service_period => 

~ ba sic_process_manageinent . infi ni te_period_count ) i 



• SPECIFICATIONS FOR USER PROCESS 4 -- 



package UPR0C4 is new Process_Definitions .Process_Instance 
( Process_S ta rtup => pr4main, 

SRO_size => 4000); 

— service_period => 

Basic Process Managen^ent . Infinite Period count); 



— BODIES FOR USER PROCESS 1 -- 



procedure prlinain is 
begin 

User_Process_l . MAIN; 
end prlmain; 



-- BODIES FOR USER PROCESS 2 -- 



procedure pr2:nain is 
beei n 

User_Process_2.main; 
end pr2main; 
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BODIES FOR USER PROCESS 3 — 



procedure prSmain Is 
begin 

User_Process_3.main; 
end pr3main; 



BODIES FOR USER PROCESS 4 -- 



procedure pr4main is 
begin 

User_Process_4.main» 
end pr4main; 



— PROCEDURE TO INITIALIZE ALL USER PROCESSES -- 



procedure Initialize 
is 

beffin 

UPROCl.Comple te_process_init iaii zation; 

— UPROC2.Complete3rocess_ini tialization; 

— UPR0C3. Comple te_process_initialization; 

— UPROC4.Coinplete_process_ini tialization; 
end Initialize; 

end User Processes; 
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DFPSEHP2.MBS 



Prafftna environment ( "ACS : BPM .MLE" ,"aCS : VlUSRP. MLl" , 

"PRIMAIN .MSS", "PR2MAIN .MSE”, "PR3MAIN,MSE”, "PR^’^AIN .mss" ) 
witn Process_Def ini tions , iMAX_Def i ni tions , 

Basic Pro cess_management ; 

with User_Process_l , Oser_Process_2 ,tTser_Process_5 , 

User_Process_4: ; 

pacicage body User_Processes is 

— Function: 

Tnis module instantiates tne user processes and 
provides an initialize procedure wnicn completes tne 

— initialization of eacn user process. 



For eacn user 
iMAX_Definitions 
process ' initial 
tnis package, tn 
tne actual ini 
another module, 
instantiation of 
wnicn specifies 
just mentioned, 
table sizes. 

Finally, tne i 
module 

Comp let e_process 
instantiation of 



process, there is an instance of 
. procedure_val which contains tn 
procedure. To minimize tne size o 
e initial procedure here simply calls 
tial procedure which is found in 
For eacn process, there is also an 
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procedure 

procedure 

procedure 

procedure 



prlma in ; 
pr2main > 
pr3main ; 
pr4main ; 



— SPECIFICATIONS FOR USER PROCESS 1 — 



package UPROCl is new Process_Def initions.Process_Instance 
( Process_S tar tup => prlmain, 

SRO_size => 4:0043); 

• se rvlce_per iod => 

basic_process_management . infini te_period_count ) ; 
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ID 



SPECIFICATIONS FOR USER PROCESS 2 — 



package UPR0C2 is new Process_Defini tions .Process_Instance 
(Process Startup => pr2maln, 

SR0_size => 40fc}0); 

— se rvlce_per iod => 

t>aslc_process_managenient . inf ini te_perioo_count ) 



— SPECIFICATIONS FOR USER PROCESS 3 — 



package UPR0C3 is new Process_Def ini ti ons .Proce ss_I ns tance 
( Process_S ta rtup => prSmain, 

SRO_size => 4000); 

— service_period => 

ba sic_process_management . inflnite_period_count ) 



— SPECIFICATIONS FOR USER PROCESS 4 -- 



pacKaae UPR0C4 is new Process_Definitions ,Process_Ins tance 
(Process Startup => pr4main, 

SRO_sizi => 4000); 

— service_per iod => 

Basic_Process_Management. Inf ini te_?eriod_count ) 



— BODIES FOR USER PROCESS 1 — 



procedure prlmain is 
begin 

bser_Process_l.MAlN ; 
end prlmain; 



— BODIES FOR USER PROCESS 2 — 



procedure pr2main is 
begin 

User_Process_2,main; 
end pr2main; 
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i 








-liii 




— BODIES FOR USER PROCESS 3 — 



procedure prSmain is 
beffin 

Use r_Process_3. main; 
end pr3main; 

— BODIES FOR USER PROCESS 4 — 



procedure pr4main is 
begin 

User_Process_4.inain; 
end pr4main; 



- PROCEDURE TO INITIALIZE ALL USER PROCESSES — 



procedure Initialize 
is 

beffin 

UPROCl.Compie te_process_ini t ial ization; 
0PR0C2. Comple te_process_ini t ial i za ti on; 

— UPR0C3.Comple te_process_i nitialization; 

— UPROC4.Complete_process_i nitialization; 
end Initialize; 

end User Processes; 
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DFPSERPS.'IBS 



Praffftia environmen t( "ACS : BPM .MLE" , " ACS : VlUSRP .MLl" , 

"PRIMAIN .MSE","PR2MAIN .MS E" , "PR3MAI N . MSE" , "PR4MAI N . MS S" ) ; 
wltn Process_Def ini tions, iMAX_Def ini tions, 

Basic_Process_manaf?errent > 

with Oser_Process_l ,Oser_Process_2 ,User_Process_3 , 

User_Proress_4; 

pactage body User_Processes is 

— Function: 

This module instantiates the user processes and 

— provides an initialize procedure wnicn completes tne 

— initialization of each user process. 

For eacn user process, mere is an instance of 

— iMAX_Def Initions .procedure_val which contains the 

process' initial procedure. To minimize the size of 

— this pacKa^e, the initial procedure here simply calls 

— the actual initial procedure wnicn is found in 

— another module. For eacn process, there is also an 

— instantiation of Process_Def ini tions. Process_I nstance 
wnicn specifies tne process id, tne procedure_va l 

— Just mentioned, and the process' staci SRO and object 

— table sizes. 



Finally, the initialize procedure provided 
module simply calls 

Comple te_pro cess _i nl tlall zat ion procedure 

instantiation of Process Definitions. Process 



by this 
tne 
in each 
Instance 



procedure 

procedure 

procedure 

procedure 



prlma in; 
pr2main ; 
pr3main ; 
pr4main ; 



— SPECIFICATIONS FOR OSER PROCESS 1 — 



pactage UPROCl is new Process_Deflni tions .Process_Insianc8 
( Process_S tartup => prlmain, 

SR0_size => 4000); 
service_period => 

basic_process_management . lnfinite_period_count ) ; 
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-- SPECIFICATIONS FOR USER PROCESS 2 -- 



package UPR0C2 is new Process_Def ini lions .Process_Ins tance 
(Process Startup => pr2main, 

SR0_size => 40^0); 

— service_period => 

basic_process_inanagement . infinite_period_count ) 



— SPECIFICATIONS FOR USER PROCESS 3 — 



package UPR0C3 is new Process_Def ini tions.Process_Instance 
(Process Startup => pr3main, 

SRO_size => 4000); 

— service_period => 

Cia sic_process_managemen t . inf i ni te_period_c ount ) 



— SPECIFICATIONS FOR USER PROCESS 4 — 



pacKage UPROC4 is new Process_Def initions .Process_Instance 
( Process_S ta rtup => pr4maia, 

SRO_size => 4000); 

— service_per iod => 

Basic_Process_Manasetnent . Inf ini te_?eriod_count ) 



— BODIES FOR USSR PROCESS 1 — 



procedure prlmain is 
begin 

Use r_Process_l. main; 
end prlmain; 



— BODIES FOR USER PROCESS 2 — 



procedure pr2main is 
begin 

User_Process_2.main; 
end pr2main; 
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— EODIES FOR USER PROCESS 3 — 



procedure prSmain Is 
beffin 

User_Process_3.main> 
end pr3main; 



— BODIES FOR USER PROCESS 4 — 



procedure pr4main is 
beffin 

User_Process_4.ma in; 
end pr4main; 



— PROCEDURE TO INITIALIZE ALL USER PROCESSES — 



procedure Initi 
is 

beffin 

UPROCl . Compie 
OPROCP.Comple 
UPROC3.Cotnple 
— UPR0C4. Couple 
end Initialize; 
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end User Processes; 
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DFPSERP4.MBS 



Praema environmenj;( ’’ aCS ;£Pf^.!^LE” ,**A.CS tVlUSRP.MLi" , 

"PRIMAIN.MSB”, ’ PR2MAIN .MSE" /'PR3MAIN.MSE","PR4:MAIN .MSS") ; 
witQ Process_Det‘ini tions , iMAX_Def initioas, 

Basic_?rocess_manaeemeni ; 

with User_Process_l , (Jser_Process_2 ,User_Process_3 1 

User_Proces s_4 ; 

package body User_Processes is 

— Function: 

This module instantiates the user processes and 

— provides an initialize procedure whicn completes the 

— initialization of each user process. 



For 

iMAX 

proc 
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the 



just 
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procedure 

procedure 

procedure 

procedure 



prlmain > 
pr2main ; 
pr3main » 
pr4ma in » 



— SPECIFICATIONS FOR OSER PROCESS 1 -- 



package UPROCl is new Process_Definitions.Process_Instance 
( Process_S tartup => prlmain, 

SRO_size => 44J00); 

— service_per iod => 

t)asic_process_ma nagemen t . inf ini te_perioc_count ) ; 
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— SPSCinCATIONS rOR USER PROCESS 2 — 



pactaee UPR0C2 Is nev Process_Def ini t ions .Process_Ir.s tance 
( Process_S tartup => pr2main, 

SRO_size => 4000); 

— service_period => 

Da sic_process_managerRent .infinite_period_count) » 



— SPECIFICATIONS FOR USER PROCESS 3 — 



pacKa^e UPR0C3 is nev Process_Definliioas .Process_Instance 
( Process_S ta rtup => pr3nain, 

SRO_slze => 4000); 

— servics_period => 

Dasic_process_managefnent . inf ini te_period_count ) ; 
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_ 




-- SPECIFICATIONS FOR USER PROCESS 4 -- 



pacKaffe UPR0C4 is new Process_I)eflRitions .Process_Instance 
(Process Startup => pr4main, 

SRO_size => 4000); 

— service_period => 

Basic_Process_Management . Inf inlte_Period_count ) 



— BODIES FOR USER PROCESS 1 — 



procedure prlmain is 
oesin 

User_Process_l. MAI N ; 
end prlmain; 



-- BODIES FOR USER PROCESS 2 -- 



procedure pr2main is 
begin 

User_Process_2.main; 
end pr2main; 



— BODIES FOR USER PROCESS 3 — 



procedure pr3main is 
beffin 

User_Process_3.main; 
end pr3main; 



-- BODIES FOR USER PROCESS 4 — 



procedure pr4main is 
begin 

Use r_Process_4. main; 
end pr4main; 



115 



— PROCEDURE TO INITIALIZE ALL USER PROCESSES -- 



procedure Initialize 
is 

beffin 

UPROCl .Comple te_process 
UPROC2.Comple te_process 
UPROC3.Complete_process 
UPROC4.Comple te_process 
end Initialize; 



initialization; 

initialization; 

initialization; 

initialization; 



end User Processes; 
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DFLINKI^LKD 



» instruction test program 

lint ACS tminmax. eoO 
ACS :textio.mlo 
intio .mso 
schar .mso 
schar .mbo 
prlmain .mso 
prSmaln.mso 
pr3main.mso 
pr4main .mso 
prlmain .mbo 
prSmain.moo 
prSmain .m bo 
pr4main.mbo 
dfpserpl .mbo 
psors .mbo 

free(30 in directory) 
output dfcharl.eod 
obj ectmap 



DFLINK2.LSD 



; instruction test program 

link ACS rmlnmax. eod 
ACS :text lo .mlo 
intio .mso 
schar .mso 
scbar .mbo 
prlmain .mso 
pr2main.mso 
pr3ma in .mso 
pr4main.mso 
prlmain .mbo 
pr2maln.mbo 
pr3main .mbo 
pr4maln.mbo 
df pserp2 .mbo 
psors .mbo 

free(30 in directory) 
output dfchar2.eod 
obJ ectmap 



DFLINK3.LKD 



; instruction test program 

linK ACS rminmai.eod 

ACS ttextio .mlo 
Intio.mso 
sctiar .mso 
scnar .mbo 
prlmain .mso 
pr2ma in .mso 
prSmain .mso 
pr4main.mso 
prlmain. mbo 
prSmain .mbo 
prSmain.mbo 
pr4main.mbo 
df pserp3.mbo 
ps ors .mbo 

free(30 in directory) 
output dfcnar3.eod 
Ob jec tmap 



DFLINE4.LKD 



; instruction test program 

lint ACS tminmax.eod 
ACS rtextio .mlo 
intio.mso 
scnar .mso 
scnar .mbo 
prlmain .mso 
pr2ma in .mso 
pr3main .mso 
pr4main.mso 
prlmain. mbo 
pr2main .mbo 
pr3main .mbo 
pr4ma in .mbo 
If pserp4 .mbo 
psors .mbo 

free(30 in directory) 



output lfcnar4.eod 
Ob jectmap 
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INFPSERPl.^BS 



Pra?ma environmen t( " aCS : SPM .MLS" , "aCS : V lUSRP .MLl” , 

"PRIMAIN .MSS", ”PR2MAIN.MSB'\"PR3MAIN.MSE’',"PR4MAIN .r^SE” ) ; 
with Process_Def ini tions , iMAX_Def ini tions, 

Basic Pro ces s_manaffement » 

with Oser_Process_l , Qser_Process_2 ,User_Froo9ss_3 , 

User_Prcces s_4 ; 

package body User_Processes is 

— Function: 

— This module instantiates the user processes and 

— provides an initialize procedure which completes the 

— initialization of each user process. 

For each user process, there is an instance of 

— iiMAX_Definitions.procelure_val which contains the 

— process' initial procedure. To minimize the size of 

— this pacicage, the initial procedure here simply calls 

— the actual initial procedure which is found in 

— another module. For each process, there is also an 

— instantiation of Process_Definitions .Process_Instance 

— Which specifies the process id, the proceaure_va i 

— just mentioned, and the process' stacK SRO ana object 
table sizes, 

— Finally, the initialize procedure provided by this 

module simply calls the 

— Complete_process_initialization procedure in each 

— instantiation of Proces5_Definitions.Process_Instance 

procedure prlmaini 
procedure prSmain; 
procedure pr3main>* 
procedure pr4main> 



— SPECIFICATIONS FOR USER PROCESS 1 — 



package UPROCl is new Process_Def initlons.Process_Instance 
( Process_S tar tup => prlmain, 

SR0_size => 4000, 
service_period => 

ba sic_process_management .inf ini te_period_count ) > 
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— SPSCinCATIONS FOR USER PROCESS 2 — 



paclcage UPR0C2 is new Process_Defini tions .Process_Ins lance 
(Process_Startup => pr2main, 

SR0_slze => 4000, 
service_perlod => 

baslc_process_nanagement .infinite_period_count ) 



— SPECIFICATIONS FOR USER PROCESS 3 -- 



pactase UPR0C3 is new Process_Definitions .Process_Iastance 
(Process_Startup => pr3main7 
SRO_size => 4000, 
service_period => 

basic_process_managerient.infinite_period_count) 



— SPECIFICATIONS FOR USER PROCESS 4 — 



pacKaffe UPR0C4 is new Process_Definitions .Process_Insiance 
( Process_S lartup => pr4main, 

SRO_size => 4000, 
serv ice_period => 

Basic_Process_^!anagement . Infinite_Period_count ) 



— BODIES FOR USER PROCESS 1 -- 



procedure prljnain is 
begin 

User_Process_l.MAIN ; 
end prlmain; 



— BODIES FOR USSR PROCESS 2 — 



procedure pr2main is 
beein 

U ser_Process_2 . main > 
end pr2main; 
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— BODIES EOR USER PROCESS 3 — 



procedure prSnnain is 
begin 

Use r_Process_3. main? 
end prSmain? 



BODIES FOR USER PROCESS 4 — 



procedure pr4.'bain is 
besrin 

User_Process_4.main? 
end pr4main? 



— PROCEDURE TO INITIALIZE ALL USER PROCESSES — 



procedure Initialize 
i s 

begin 

UPROCl . Comple te_process_ini tialization? 

— UPROC2.CoTipiete_process_ini tialization? 

— UPR0C3. Comple te”p^ocess_ini tialization? 

— UPR0C4. Comple te_process_i ni tialization? 
end Initialize? 

end User Processes? 
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Pragma envi ronmen "ACS : BP^* . '^LE” ACS : VIUSRP .MLI " , 

PRIMAIN.MSE", ’ PR2MAIN.MSE" ♦"PR3MAIN.MSE" /’PRaMAIN .5^SS” ) J 
with Process_Defini tions , iMAX_Def ini tions , 

Ba sic_Process_managemer t > 

with User_PrDcess_l , User_Process_2 ,User_Process_3 , 

Dser_Process_4; 

pacKaffe body User_Processes is 

— Function: 

This module instantiates the user processes and 

— provides an initialize procedure which completes the 
initialization of each user process. 

For each user process, there is an instance of 

— iMAX_Definiti ons . procelure_val which contains the 

— process' initial procedure. To minimize the size of 
this pacicage, the initial procedure nere simply calls 

— the actual initial procedure which is found in 

— another module. For each process, there is also an 

— instantiation of Process_Def initions .Process_Instance 
Which specifies the process id, tne procedure_vai 
Just mentioned, and the process' stacic SRO ana object 
table sizes. 

— Finally, the initialize procedure provided by this 

module simply calls the 

— Complete_process_ini tialization procedure in each 

— instantiation of Process_Def ini tions. Process_Instance 

procedure prlmain; 
procedure pr2main» 
procedure pr3main; 
procedure pr4main; 



-- SPECIFICATIONS FOR USER PROCESS 1 — 



pacKase UPROCl is new Process_Def initions .Process_Instance 
( Process_S tar tup => prlmain, 

SRO_size => 4ei!0, 
service_per iod => 

basic_process_management . inf ini te_period_count ) » 
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-- specifications for user process 2 — 



pacFase UPH0C2 is new Process_Definitions .Process_Ir.stance 

(Process Startup => pr2main, 

SRO_size => 4000, 
service_period => 

basic_procsss_management . infini te_ period _count ) 



-- SPECIFICATIONS FOR USER PROCESS 3 -- 



pacKa^e UPR0C3 is new Process_refinitions .Process_Instance 
(Process Startup => pr3main, 

SRO_size => 4000, 
ssrvice_period => 

Dasic_process_management . inf inite_period_count ) 



— SPECIFICATIONS FOR USER PROCESS 4 — 



pacKa^e UPR0C4 is new Process_Eeflniiions.Process_Instance 
(Proces s_S ta rtup => pr4main, 

SRO_size => 4000, 
service_periol => 

3asic_Process_’^anagement .Infini te_Period_count ) 



— BODIES FOR USER PROCESS 1 — 



procedure prl.nain is 
begin 

Oser_Process_l.MAIN; 
end prlmain; 



— BODIES FOR USSR PROCESS 2 — 



procedure pr2nain is 
begi n 

User _Process_2. main; 
end pr2main; 
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-- BODIES FOR USER PROCESS 3 — 



procedure prSmain is 
begin 

User_Process_3.main ; 
end pr3main» 



— BODIES FOR USER PROCESS 4 — 



procedure pr4main is 
begin 

User_Process_4.main> 
end pr4main; 



— PROCEDURE TO INITIALIZE ALL USER PROCESSES -- 



procedure Initialize 
is 

begin 

UPROCl .Conpiete_process 
OPROC2.Complete_process 

— UPROC3.Cotnple te_process 

— UPR0C4.Complete_process 
end Initialize; 



initialization; 
initialization; 
ini tialization; 
ini tiali za tion; 



end User Processes; 
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iiiIPSERP3iMBS 

Pragma envlronment( "aCS :BP^! .MLK” ,”aCS :VlUSRP.MLl" , 

'PRIKAIN.MSE", ‘'PR^MAIN.MSE■^"PR3MAIN.MSE'‘ ,“PR4MAIN .51SE") ; 
tfitu Process_Def ini tions , iMAX_Definitions, 

Basic Process managerr’ent » 

witQ User_Process_l ,User_Process_2,User_Process_3, 

User_Process_4i 

pacKaffe oody Qser_Processes is 

— Function: 

— This module instantiates tiie user processes and 

— provides an initialize procedure wnicti completes tne 

— initialization of eacn user process. 

— For eacn user process, tnere is an instance of 

— iMAX_Definitions, procelure_val wnich contains tne 

— process' initial procedure. To minimize tne size of 

— tnis pactage, tne initial procedure nere simply calls 

— the actual Initial procedure wnicn is found in 

— anotner module. For eacn process, tnere is also an 
instantiation of Process_Def initions .Prccess_Instance 

— wnicn specifies the process id, the procelure_vai 
Just mentioned, and the process' stacs SRO and ooject 
table sizes. 

Finally, the initialize procedure provided by tnis 
module simply calls tne 

Complete_process_ini tiallzation procedure in eacn 
instantiation of Process_Def ini tions . Process_I nstance 

procedure prlmainj 
procedure pr2main? 
procedure pr3main; 
procedure pr4main» 



— SPECIFICATIONS FOR OSER PROCESS 1 — 



paciaffe UPROCl is new Process_Def ini tions . Pro cess_I nstance 
( Process_S tar tup => prlmain, 

SR0_size => 
service_period => 

Da sic_process_management . inf i ni te_period_count ) ; 
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-- SPECIFICATIONS FOR USER PROCESS 2 — 



pacicage UPR0C2 is new Process_Del'ini tions .Process_Ins tance 
( Process_S la rtup => pr2main, 

SRO_size => 4000, 
service_period => 

Dasic_process_mana«erTient . inf ini ie_periO(i_count ) ; 



-- SPECIFICATIONS FOR USER PROCESS 3 -- 



pacnage UPR0C3 is new Process_Def initions .Process_Insiance 
( Process_S tariup => pr3main, 

SRO_size => 
service_periol => 

basic_process_manaeement.ini’ini te_period_count ) ; 



— SPECIFICATIONS FOR USER PROCESS 4 -- 



passage UPR0C4 is new Process_Definitions .Process_Insiance 
(Process_Startup => pr4main, 

SRO_size => 4000, 
serv ice_period => 

Basic Process Ma nasement . Inf ini le Period count). 



“ BODIES FOR USER PROCESS 1 -- 



procedure prlTiain is 
begin 

User_Process_l.MAIN; 
end prlmain. 



-- BODIES FOR USER PROCESS 2 -- 



procedure pr2main is 
fcesin 

U ser_Process_2.main 
end pr2main; 
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— £ODI£S FOR USER PROCESS 3 — 



procedure pr3:rialn is 
Desin 

Us£r_?roces5_3.main; 
end pr3maln; 



-- BODIES FOR USER PROCESS 4 — 



procedure pr4main is 
tegin 

User_Process_4.main; 
end pr4main; 



~ PROCEDURE TO INITIALIZE ALL USER PROCESSES — 



procedure Initialize 



is 

oesin 



UPROCl .CoTipie 
UPR0C2.Cotnpie 
UPR0C3.C07ipl9 
— UPROC4. Compie 
end Initialize; 



te_process 

te_process 

te~process 

te_process 



initializa 
ini t ial i za 
ini tiaiiza 
initializa 



tion 

tion 

tion 

tion 



t 

y 

f 



rocesses; 



end User P 



INFPSSRP4:.MBS 



Pragma en vi ronmen t ( "ACS : BPM. MLE" , ” ACS :71USRP .riLI " , 

"PRIMA IN .MSE" , "PR2MAI N .MSE" , "PR3f^A IN . MSE" , "PR4f^AlN .MS E” ) ; 
with Process_Def i ni tions , lMAX_Def initions , 

Basic Proce5s_rraaaffeMent ; 

with Qser_Process_l , Use r_Pro cess _2 ,User_?rocess_3 , 

Usir_Process_4; 

pacttaffe hody User_Processes is 

— Function: 

This module instantiates tne user processes and 

— provides an initialize procedure which completes the 
initialization of each user process. 

— For each user process, there is an instance of 
iMAX_Definitions.procedure_val which contains the 
process' initial procedure. To minimize the size of 

— this pacKaffe, the initial procedure here simply calls 

— the actual initial procedure which is found in 

— another module. For each process, there is also an 

— instantiation of Process_Definitions.Process_Instance 

— which specifies the process id, the procedure_va 1 

— just mentioned, and the process' stacic SRO and object 
table sizes. 

Finally, tne initialize procedure provided by tnis 

— module simply calls tne 

— Complete_process_initiallzation procedure in each 
instantiation of Process_Def ini tions . Process_I ns tance 

procedure prlmain; 
procedure pr2main; 
procedure pr3main; 
procedure pr4mainj 



— SPECIFICATIONS FOR USER PROCESS 1 — 



pacirage UPROCl is new Process_Definitions.Process_Instance 
(Process Startup => prlmain, 

SR0_size => 4000, 
service_perlod => 

basic_process_management .infinite_period_count); 
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— SPECIFICATIONS FOR USER PROCESS 2 — 



package UPR0C2 is new Process_Def ini tions .Process_Ins tance 
(Process Startup => prRmain, 

SRO_size => 4000, 
service_period => 

basic_process_ruanagement . infini te_period_count ) 



— SPECIFICATIONS FOR USER PROCESS 3 — 



pacSrage UPR0C3 is new Process_Definitions .Process_Instance 
{ ?rocess_Startup => pr3main, 

SR0_size => 4000, 
se rvice_period => 

basi c_process_:nanagerTient . inf l ni t e_period_count ) 



— SPECIFICATIONS FOR USER PROCESS 4 — 



pacJcase UPROC4 is new Process_Definitions .Process_Instance 
( Process_S tartup => pr4maln, 

SRO_size => 4000, 
service_per iod => 

Ba slc_Process_Management .Infinite_Period_count ) 



-- BODIES FOR USER PROCESS 1 — 



procedure prlmain is 
beffin 

User_Proce ss_l. MAIN ; 
end prlmain; 



— BODIES FOR USER PROCESS 2 — 



procedure pr2main is 
begin 

User _Process_2. main; 
end pr2main; 
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— BODIES FOR USER PROCESS 3 -- 



procedure prSmain is 
be^in 

Oser_Process_3.tnain; 
end pr3main; 



-- BODIES FOR USER PROCESS 4: -- 



procedure pr^main is 
begin 

User_Process_4.ma in; 
end pr4tnain; 



— PROCEDURE TO INITIALIZE ALL USER PROCESSES — 



procedure Initialize 
is 

begin 

UPROCl.Complete_process 
UPR0C2 ,Co:nple te_process 
UPR0C3.Complete_process 
UPROC4.Comple te_process 
end Initialize; 



ini tiaiization; 
initialization; 
initialization; 
initialization; 



end User Processes; 
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INLINKI.LKD 



i instruction test program 

linK ACS tminma I. eod 

ACS : text io .mio 
intio .mso 
schar .mso 
scnar .mbo 
prlma in .mso 
prZmain .mso 
prSmain .mso 
prdmain.mso 
prlmain.mbo 
pr2main .mbo 
pr3main.mbo 
pr4main.mbo 
inf pserpl .m bo 
psors .mbo 

free (30 in directory) 
output infcnarl.eod 
objectmap 



INFLINK2iLKD 

; instruction test program 

link ACS rminmax. eod 
ACS next io .mlo 
intio .mso 
schar .mso 

schar .mbo 
prlmain .mso 
pr2main .mso 
pr3main .mso 
pr4main.mso 
prlmain .mbo 
pr2main.mbo 
pr3main .m bo 
prlmain.mbo 
inf pserp2 .mbo 
psors .mbo 

free(30 in directory) 
output infchar2.eod 
objectmap 
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INFLINK3.LKD 



; instruction test proeram 

lint ACS tminmai.eod 

ACS : textio .mlo 

intio .mso 

scnar .mso 

schar .mbo 

prlmain.mso 

pr2main.mso 

prSmain .mso 

pr4main.mso 

prlmain .m bo 

pr2main.mbo 

pr3main .mbo 

prAmain.mbo 

inf pserp3 .mbo 

psors .mbo 

free(30 in directory) 
output infchar3.eod 
objectmap 



INFLINK3^LKD 

; instruction test proeram 

iini ACS :minmax.eod 

ACS : teitio .mlo 

intio .mso 

scnar .mso 

scnar .mbo 

prlmain.mso 

pr2main.mso 

pr3main.mso 

pr4main.mso 

prlmain .mbo 

pr2main.mbo 

pr3main .mbo 

pr4 main. mbo 

inf pserp4.mbo 

psors .mbo 

free(30 in directory) 
output infcnarA.eod 
objec tmap 
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JCHAHl .COM 



^ada432new 

$lda ACS :intio .mss 

Sida scnar.mss 

$ida schar.mbs 

$ida Irosers. common] prlmain 

$lda [rogers .common j pr2main 

$lda [rogers .common] prSmain 

Hda [rovers .common] prAma In 

$pu rge 



mss 

mss 

mss 

mss 



$ida prlmain 
$ida pr2maln 
^ida prSmain 
$ida pr4main 
$purse 

$ida [rogers 
$ida [rogers 
$ida [roeers 
$ida [rogers 



$purge 

$lda [rovers 
$ida [rogers 



$lda 

$lda 

Sida 



.rogers 

.rogers 

roeers 



mbs 
mbs 
m bs 
m bs 

common] dfpserpl.mbs 
common] dfpserp2.mbs 
common] df pse rp3 .mbs 
common] dfpserp4.mbs 

common] infpserpl .mbs 
common] inf pserp2 .mbs 

common] inf pserp3 .m bs 
common] inf pserp4.mbs 
common] psors .mbs 



Spurge 

$linlc432 

$llnic432 

Sllnt432 

Slink432 

$link432 

$link432 

Slink432 

$iink432 
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